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PREFACE 


This  report  was  prepared  by  the  Institute  for  Defense  Analyses  (IDA)  for  the  Office 
of  the  Secretary  of  Defense,  Manpower,  Reserve  Affairs  and  Logistics  Under  Contract 
Number  MDA  903  84  C  0031,  Task  Order  T-3-192,  "R&D  Support  to  Improve  Force 
Readiness." 

The  issuance  of  the  report  answers  the  specific  task  to  "...assemble  a  group  of  both 
industry  and  government  personnel-experienced  in... computer-aided  technologies  for 
automation  of  support  procedures  in  order  to  examine  issues. ..include(ing)  the 
subcontractor  level,  inventory  management  techniques,  etc.  At  present  these  issues  are 
being  addressed  individually  without  apparent  consideration  of  their  interaction  in  meeting 
the  total  DoD  objective... to  evolve  a  general  plan  for  automated  support  of  DoD  operating 
systems  which  addresses  the  problems  of  interaction  between  the  different  systems  now  in 
use  or  evolving,  and  the  various  approaches  being  taken  by  DoD  to  address  its  readiness 
problems." 
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ARCHITECTURE  SUBGROUP  REPORT 


SECTION  I:  INTRODUCTION 
A.  INTRODUCTION 

This  volume  is  intended  to  document  the  efforts,  findings,  and  recommendations  of 
the  Architecture  Subgroup  of  the  CALS  Ad  Hoc  Group. 

This  subgroup  was  chartered  to  provide  an  architectural  framework  for  a  CALS 
system  that  would  allow  DoD  to  make  full  use  of  contractor-generated  digital  data,  and  to 
determine  implementation  considerations  for  the  near  term  (the  next  5  years)  and  longer 
term  (10-15  years)  timeframes  to  achieve  this  objective. 


B.  ARCHITECTURE  SUBGROUP  APPROACH 

T^-  '  J'X'  .(J*  *'  tOC..  ■  J 

The  Subgroup  began  its  efforts  by  evaluating5the  various  interpretations  of  an 

C  t  o. 

"architecture  (data  flow,  hardware,  software,  system,  geographical,  organizational,  etc.) 
which  could  be  used  to  characterize  the  CALS  system. 

The  architecture  was  viewed  as  serving  several  purposes: 

a.  To  provide  the  wsystemw>  concept  to  tie  together  the  many  diverse 
considerations  involved  in  such  a  very  large  integration  effort. 

b.  To  scope  the  CALS  system  and  its  functions  fer-the  Ad  Hoc  Group  lo  as  to 
focus  the  efforts  of  the  other  subgroups  (Technical  Issues,  Data 
Requirements,  and  Policy/Legal  Issues). 

c.  To  provide  an  initial  foundation  upon  which  the  further  development  and 
implementation  of  the  target  system  could  rest. 

d.  To  describe  the  target  system  in  such  a  way  that  it  could  be  readily 

understood  and  acted  upon  by  government  and  industry.  _ 

The  Subgroup  decided  that  these  purposes  could  be  best  realized  in  the  time  allotted 
by  developing  a  functional  description  of  CALS  which  could  later  be  refined  and  expanded 
into  the  needed  architectures.  It  was  further  decided  that  this  description  should  be  in  terms 
of  the  types  of  information  which  are,  or  should  be,  associated  with  each  CALS  function, 
and  the  computerization  of  the  generation,  modification,  storage,  retrieval,  distribution,  and 
use  of  that  information. 


In  order  to  define  the  boundaries  of  CALS,  the  Subgroup  developed  a  list  of  CALS 
functions  and  associated  data  types  for  the  desired  target  system.  The  list  was  divided  into 
two  parts:  Contractor  Functions;  DoD  Functions  (see  Section  II,  Tables  II- 1  and  II-2). 
These  lists  then  became  the  de  facto  definition  of  the  functions  within  the  CALS  purview. 
As  discussed  in  this  volume,  the  data  types  associated  with  each  function  are  broad,  generic 
classes  of  information  produced  or  utilized  in  the  performance  of  each  function. 

2.  CALS  Issues  Matrix 

Major  CALS  issues  identified  by  the  Architecture  Subgroup  were  discussed  and 
tabulated.  They  were  then  reviewed  to  note  which  subgroups  might  appropriately  address 


each  issue  and  distributed  accordingly.  The  matrix  of  issues  is  shown  in  Table  1-1. 

3.  Functional  Description  of  Target  System 

To  produce  an  adequate  functional  description  of  the  target  system  concept,  several 
complementary  descriptive  elements  were  selected,  and  assignments  to  produce  them  were 
accepted  by  Subgroup  members.  They  were  as  follows: 

•  Concept  Papers  -  describing  the  ways  in  which  selected  logistics  functions  will  be 
performed  in  their  computerized  implementation  in  10  to  15  years,  and  identifying 
implementation  considerations  and  likely  payoffs. 

•  A  Graphical  Mode/Representation  -  of  target  system  functions,  relationships  and 
information  flows. 

•  Narrative  Descriptions  -  of  the  graphical  model  elements,  giving  the  status  of  the 
existing  implementations,  the  target  system  characteristics,  the  benefits  of 
automating,  integrating,  standardizing,  etc.,  anticipated  problems,  projected 
solutions,  and  rough  qualitative  estimates  of  implementation  costs. 

Modeling  techniques  and  languages  to  represent  the  relationships  between  functions 

and  the  concomitant  flow  of  information  were  investigated  and  presented.  The  ICAM 
Definition  Language  (IDEF0)  Functional  Model  was  selected  as  the  best  approach  for 

several  reasons:  its  hierarchical  structure  allowed  the  Subgroup  to  use  a  top-down 
approach  and  add  detail  as  time  permitted;  several  Subgroup  participants  were  familiar  with 
EDEF  so  that  outside  expertise  was  not  required;  and  support  was  available  to  computerize 
the  "model,"  allowing  for  rapid  additions  and  modifications.  A  brief  description  of  the 
IDEF0  methodology  is  given  in  Section  C. 


Table  1-1.  CALS  ISSUE  MATRIX 


Table  1-1.  CALS  ISSUE  MATRIX  (Continued) 


Issue 

Group 

Assignment 

Architecture 

Issues  Priorities 

9.  How  will  the  CALS  system  be  partitioned  into 
manageable  subsystems? 

.  By  Data 
.  By  Functions 
.  By  Process 

Architecture 

Technology 

1 

10.  How  to  determine  which  existing  CALS  should  be 

•  Retained 

•  Modified 

•  Replaced 

•  Eliminated 

Architecture 

Policy 

3 

1 1  •  How  should  the  CALS  be  structured  to  accommodate 
the  desired  enhancement  in  the  design  process? 
(Maintainability,  Diagnostics,  Embedded  Maintenance 
and  Training) 

Architecture 

1 

12.  How  should  DoD  incentivize  the  changes  in  the  design 
process? 

Policy 

1 3.  How  will  configuration  control  be  implemented  within 
the  CALS? 

Technology 

14.  How  should  CALS  be  structured  to  enhance  the 
effectiveness  of: 

.  Training 
.  Maintenance 
.  Re-procurement 
.  Post-production 
.  Support 

Architecture 

1 

15.  Is  a  total  paperless  system  a  desired  objective?  If  not, 
to  what  extent? 

Architecture 

Policy 

3 

1 6.  Which  subsystems  or  functions  should  be  computerized? 

Architecture 

3 

NOTE:  Priority  1  -  Essential  (Continued) 

2  -  Desirable 

3  -  Least  Essential 


I 


I 


Issue 

Group 

Assignment 

17.  How  should  archiving  be  accomplished? 

•  What  Data 

•  How  Long 

•  What  Medium 

•  Disaster  Protection 

Technology 

Data 

18.  How  can  the  Government  logistics  data  be  accessed 
through  CALS? 

(Standard  Parts,  Inventory,  Field  Experience) 

Technology 

Policy 

19.  What  additional  data  should  the  Government  collect 
and  supply? 

Data 

20.  Who  within  DoD  will  be  responsible  for  implementing 
CALS? 

Policy 

21.  What  vehicles  should  the  DoD  employ  to  advance  die 
identified  technology? 

Policy 

Architecture 
Issues  Priorities 


NOTE:  Priority  1  -  Essential 

2  -  Desirable 

3  -  Least  Essential 


From  the  knowledge  and  information  obtained  while  developing  these  output 
products,  the  Subgroup  was  then  able  to  assemble  a  series  of  recommendations  and  devise 
appropriate  demonstration  projects  to  carry  those  recommendations  into  working  systems. 
These  recommendations  and  demonstration  projects  appear  in  Sections  III  and  IV, 
respectively. 

Time  did  not  permit  concept  papers  or  IDEF  representations  to  be  produced  for  all 
CALS  functions.  Those  that  were  completed  appear  in  Section  II  by  function  in  the 
following  order: 

Top  Level  IDEF  Function  Chart 
Concept  Paper  or  Narrative  Description 
Lower  Level  IDEF  Charts 
IDEF  Narrative. 

C.  EXPLANATION  OF  THE  IDEF  METHODOLOGY 

1.  Overview 

The  IDEF0  or  functional  model  of  the  architecture  is  the  structured  approach 
employed  to  achieve  program  definition  of  subsystems  and  systems  as  well  as  a  generic 
representation  of  Computer-Aided  Logistics  Support  (CALS). 

The  brief  explanation  that  follows  is  designed  to  acquaint  someone  having  no  prior 
exposure  to  IDEF0  with  its  methodology  and  provide  them  with  sufficient  information  to 

read  and  understand  IDEF0  models. 

2.  Description 

IDEF0  is  a  structured  approach  to  produce  complete  program  definition.  This  "top- 
down"  approach  can  be  visualized  as  an  expanding  pyramid  structure  (see  Figure  1-1).  A 
function  at  the  top  can  be  decomposed  into  a  number  of  subfunctions;  in  this  case,  the 
"A-ZERO"  function  consists  of  four  subfunctions.  Any  of  these  subfunctions  can  be 
further  decomposed,  as  shown  by  subfunction  box  A-2,  which  breaks  down  into  three 
lower  level  functions,  A-21,  A-22,  A-23.  These  functions  are  then  separated  into  distinct 
steps  as  shown  by  function  A-21  breaking  down  into  three  lower  functions  and  function 
A-22  breaking  down  into  four  lower  functions;  A-23  has  no  lower  function.  The  process 
is  continued  until  the  architect  of  the  model  achieves  the  level  of  understanding  he  requires. 
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This  "top-down"  approach  is  necessary  to  obtain  complete  program  definition  with 
all  functions  described  at  their  proper  level  in  the  hierarchy.  At  this  point  one  can  choose  a 
collection  of  steps,  operations  or  functions  and  build  a  (computer)  system  to  support  the 
model,  or  simulate  its  behavior. 

The  structured  approach  assures  proper  consideration  of  all  constraints  and 
interfaces  of  the  model.  Developments  then  utilize  a  "bottom-up"  construction  approach. 
The  modeling  assures  that  these  developments  will  be  upward-compatible,  i.e.,  they  will 
INTEGRATE. 

3.  Methodology 

In  building  an  IDEF0  (functional)  model,  the  system  is  viewed  as  a  collection  of 

diagrams  composed  simply  of  labeled  rectangular  boxes  with  interfaces  identified  by 
directed  lines  (arrows)  (see  Figure  1-2).  The  boxes  represent  activities  and  the  arrows 
represent  "objects"  processed  by  the  system.  By  "objects"  are  meant  any  substantive  noun 
item  ranging  from  tangible  objects  to  abstract  information.  The  activity  in  a  box  can  be 
anything  denotable  by  an  active  verb,  whether  a  concrete  or  a  conceptual  action.  Examples 
include  "tighten,"  "attach,"  "measure,"  "assemble,"  "classify,"  "construct,"  "solve," 
"adapt,"  "consider,"  "develop,"  etc.  Activities  do  not  include  functions  expressed  as 
nouns,  such  as  "maintenance,"  nor  are  they  passive  in  form.  The  arrows  represent  objects 
or  anything  describable  by  a  noun  phase. 

The  Functional  Model,  then,  is  a  collection  of  activity  diagrams  that  decompose  a 
complex  operation  or  subject  into  its  component  parts.  The  initial  diagram  is  the  most 
general  or  abstract  description  of  the  entire  system.  This  diagram  shows  each  major 
component  as  a  box.  The  details  —  or  "insides"  --  of  every  component  "box"  are  shown  on 
other  diagrams  at  a  lower  hierarchical  level.  These  lower  ranking  diagrams  also  show  their 
components  as  even  lower-ranking  boxes  —  and  so  on  to  any  desired  level  of  detail. 

Each  detailed  diagram  presents  a  finer  description  of  just  one  box  on  its  "parent" 
diagram  (see  Figure  1-3).  Arrows  entering  and  leaving  the  parent  box  are  exactly  those  in 
the  "child"  diagram.  The  activity  verb  in  a  "parent  box"  is  always  a  broader,  more 
generalized  term  than  those  identifying  boxes  in  successively  lower  diagrams. 
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IDEfjj  Diagrams  Are  Composed  of:  •  Boxes 

•  Arrows 

•  Labels 

Activity  An  activity  is  represented  by  a  box. 

Input  Data  which  are  transformed  by  a  box. 

Output  Data  which  results  from  a  process  -  data  created  by  the  activity. 

Mechanism  Mechanisms  provide  the  means  of  convening  input  data  to  output 
data.  A  mechanism  may  show  how  the  activity  is  accomplished. 

Control  Data  which  influence  or  determine  the  process  of  converting  inputs 

to  outputs.  A  control  describes  the  conditions  or  circumstances 
that  govern  the  transformation  of  input  to  output.  Every  activity 
must  have  at  least  one  control. 


Figure  1-2.  IDEF0  LANGUAGE  FUNDAMENTALS 
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EVERY  COMPONENT  MAY  BE  DECOMPOSED  IN  ANOTHER  DIAGRAM. 
EVERY  DIAGRAM  SHOWS  THE  "INSIDE"  OF  A  BOX  ON  A  HIGHER 


Figure  1-3.  IDEF  DIAGRAMMING  HIERARCHY 


SECTION  II:  SYSTEMS  CONCEPT  OVERVIEW 


A.  INTRODUCTION 

Tables  II- 1  and  II-2,  respectively,  delineate  the  list  of  CALS  functions  and 
associated  data  types  for  Contractor  Functions  and  DoD  Functions.  The  data  types 
associated  with  each  function  are  broad  generic  classes  of  information  produced  or  utilized 
in  the  performance  of  each  function. 

Annex  1  to  this  volume  supports  Table  II- 1  in  providing  working  papers  and 
briefing  reports  documenting  CALS  Contractor  Functions.  Annex  2  documents  CALS 
DoD  Functions.  Both  annexes  can  be  found  at  the  back  of  this  volume. 


AO  PROVIDE  CALS,  CONTRACTOR  FUNCTIONS 


A1  PERFORM  LOGISTICS  MANAGEMENT 

A1 1  Provide  Configuration  Management 

A 1 2  Provide  Cost  and  Schedule  Control 

A121  Provide  Cost  Control 
A122  Provide  Schedule  Control 

A13  Manage  Support  Resources 
A2  INFLUENCE  DESIGN/MODIFICATION 


A21 

Provide  Design  Guidance 

A22 

Perform  Allocations 

A221 

Initiate  Diagnostic  Procedure 

A222 

Partition  Equipment 

A223 

Establish  Reliability  Allocation 

A224 

Conduct  Trades 

A225 

Maintainability  Allocations 

A226 

Provide  First  Cut  Failure  Mode  Effects  and  Criticality  Analysis 

A23 

Perform  Equipment  Design 

A24 

Perform  Analyses 

A241 

Perform  Reliability  Stress  Analyses 

A242 

Perform  Testability  Analyses 

A243 

Perform  FMECA 

A244 

Perform  Transportability  and  Repair  Level  Analyses 

A245 

Perform  Maintainability  Analyses 

A246 

Perform  Human  Factors  and  Safety  Analyses 

A25 

Support  Trades 

A251 

Perform  Repair  Level  Analysis 

A26 

Demonstrate  and  Approve 

A261 

Develop  Procedures 

A262 

Perform  Valications/Demos:  Reliability  Maintainability  Supportability 

A263 

Assimilate  Analyses  Results 

Table  II-l.  IDEF  BREAKDOWN  STRUCTURE  FOR 
CALS  CONTRACTOR  FUNCTIONS,  AO  (Concluded) 


A3  PROVIDE  LOGISTICS  RESOURCES 

A31 

Provide  Contractor  Field  Support 

A311 

Provide  Trained  Contractor  Personnel 

A312 

Accomplish  Site  Activation 

A313 

Provide  Depot  Support/Operation 

A3 14 

Provide  Production/Post-Production  Support 

A3 14 1  Provide  Maintenance  Service  Information 

A3 142  Perform  Maintenance 

A3143  Provide  System  Specific  Expertise 

A321 

Define  and  Acquire  Training  Equipment 

A322 

Develop  Courses 

A323 

Conduct  Training  for  Government  Personnel 

A33 

Prepare  Maintenance  and  Operation  Data 

A331 

Develop/Update  Maintenance  and  Operation  Data 

A332 

Validate/Verify  Maintenance  and  Operation  Data 

A333 

Deliver/ Archieve  Maintenance  and  Operation  Data 

A34 

Perform  Test  and  Evaluation 

A341 

Plan  Test 

A342 

Conduct  Test  Program 

A343 

Evaluate  Test  Data/Results 

A35 

Perform  Manufacture 

A351 

Plan  for  Manufacture 

A352 

Make  and  Administer  Schedules  and  Budgets 

A353 

Plan  Production 

A354 

Provide  Production  Resources 

A355 

Obtain  Manufacturing  Materials 

A36 

Provide  Logistics  Systems 

A361 

Develop  Support  System 

A362 

Prepare  Logistic  Support  Analysis  Record 

A363 

Develop  Support  Equipment  Specifications 

A364 

Develop  Facilities  Design  Criteria 

A365 

Plan  Transportability 

_ 

A366 

Develop  Instructional  System 

Table  II-2.  IDEF  BREAKDOWN  STRUCTURE  FOR 
CALS  DoD  FUNCTION,  AO 

AO  PROVIDE  CALS,  DoD  FUNCTION 

A1  PROVIDE  SUPPORT  ACQUISITION  AND  MANAGEMENT 
All  Perform  Configuration  Management 

A 1 1 1  Establish  Configuration  Baseline 

A 1 1 2  Provide  Configuration  Control 

A1 13  Implement  Logistics  Support  Analysis 

A12  Perform  System  Life  Cycle  Management 

A121  Conduct  Logistics  Support  Planning 

A122  Conduct  Support  System  Acquisition 

A123  Manage  Deployed  Systems  Support 

A13  Perform  Resource  Planning 
A14  Provide  Support  Acquisition 
A15  Accomplish  Site  Activation 

A2  PROVIDE  TRAINING 

A121  Define  and  Acquire  Training  Equipment 
A 1 22  Develop  Courses 
A 1 23  Conduct  Training 

A3  PERFORM  MAINTENANCE 

A3 1  Provide  Maintenance  Management 

A32  Inspect/Diagnose  Failure 

A33  Perform  Repair  and  Check  (Any  Level) 

A34  Perform  Overhaul 

A35  Record  Maintenance  Action  Data 

A36  Perform  Failure  Analysis 

A4  PERFORM  MODIFICATION 

A41  Generate  Redesign  Requirement 
A42  Redesign  Item 

A43  Remanufacture  Item  (Contractor/Depot) 

A44  Perform  Field  Modification  (DS/GS/Depot) 

AS  PERFORM  TEST  AND  EVALUATION 

A5 1  Plan  Test  Program 
A52  Conduct  Test  Program 
A53  Evaluate  Test  Data/Results 

A6  PROVIDE  SUPPLY  SUPPORT 


A61  Perform  Inventory  Management 
A62  Acquire  Material 
A63  Store  and  Distribution 


SECTION  III.  CONSOLIDATED  RECOMMENDATIONS 


A.  OVERVIEW 

The  recommendations  contained  in  this  section  represent  the  major  concerns  of  the 
Architecture  Subgroup  in  making  CALS  a  reality.  The  order  of  presentation  has  no  bearing 
on  the  importance  of  the  recommendation  on  that  objective,  but  rather  on  the  timing  and 
ease  of  implementation,  given  the  state-of-the-art  today.  However,  all  of  the  recommended 
actions  are  required,  at  least  to  some  degree,  to  ensure  implementation  and  utilization  of 
CALS. 

If  one  were  to  attempt  to  rank  the  recommendations  in  order  of  importance  to  the 
objectives  to  improve  readiness  and  sustainability  by  taking  advantage  of  computer-aided 
design,  drafting  and  manufacturing,  the  order  would  be: 

•  Incentivize  industry  to  move  forward  with  the  design-influencing  issues  of 
CALS. 

•  Motivate,  educate  and  direct  the  Government  agencies  to  make  maximum  use  of 
CALS. 

•  Resolve  the  data  item  issues. 

The  recommendations  conclude  that  specific  details  of  action  within  these 
recommendations  must  be  developed.  To  do  that,  specific  areas  need  to  be  expanded  by 
the  CALS  Ad  Hoc  Group,  work  statements  prepared,  and  outside  activities  monitored  and 
guided.  All  these  are  activities  that  should  be  started  if  the  recommended  actions  were 
accepted,  and  will  therefore  require  that  certain,  specific  group  activities  be  continued,  as 
discussed  in  the  paragraphs  that  follow. 


a.  Approach 

Given  the  traditional  reluctance  of  DoD's  functional  logistics  personnel  to  deviate 
from  the  classic,  hard-copy  data  item  requirements  (DIDs)  for  specific  deliverable  formats, 
and  the  fact  that  present  contracts  and  RFPs  require  both  the  classic  formats  and  duplicative 
LSAR  outputs  to  be  delivered,  the  following  approach  to  near-term  (within  3  years) 
integration  of  MIL-STD-1388's  LSAR  requirements  with  those  of  other  support-related 


DIDs  is  recommended.  This  approach  will  minimize  the  organizational  and  cultural  impact 
of  the  transition  from  standard  DIDs  to  digitized  data/information  transfer  upon  the 
Services.  At  the  same  time  it  will  reap  the  benefits  of  an  integrated  data  source  (prepared 
from  the  "standard  and  Neutral  Formats"),  common  audit  trail,  common  configuration 
control,  and  standardized  Service/industry  interfaces. 

The  recommendation  is  to  initiate  a  funded  task  to  develop  the  capability  to  produce 
the  full  range  of  logistics  data  items  (DIDs)  from  the  LSAR  data  base  and  demonstrate  the 
feasibility  of  on-line  terminal  delivery  of  data  normally  delivered  in  hard-copy  DID  formats. 
Development  of  the  capability  to  produce  support-related  DIDs  from  the  LSAR  should 
proceed  as  follows: 

a.  Conduct  a  study  to  identify  the  data  elements  required  to  produce  the  classic 
logistics  data  items  (including,  but  not  limited  to,  GSERD,  CMRS,  Task 
and  Skills  Analysis,  Technical  Publications,  Provisioning  Technical 
Documentation,  Illustrated  Parts  Breakdowns  and  R&M  analysis  data,  etc.) 
which  are  not  contained  in  the  LSAR  data  element  dictionary. 

b.  Develop  the  software  necessary  to  process  the  additional  data  elements 
identified  in  (a)  above  and  produce  the  classic  logistics  data  items  from  the 
LSAR  data  files.  Demonstrate  the  use  of  this  software  in  a  realistic  logistics 
planning  environment. 

c.  Incorporate  the  additional  data  elements  identified  in  (a)  above  into  MIL- 
STD-1388  and  upgrade  the  DoD  LSAR  ADP  system  to  include  the 
capabilities  demonstrated  in  (b)  above. 


b.  Parallel  Effort 


In  parallel  with  the  effort  discussed  above,  initiate  an  effort  to  demonstrate  the 
benefits  of  on-line  logistics  data  delivery  to  the  user  of  those  data.  This  effort  should  be 
conducted  as  follows: 


a. 


b. 


c. 


d. 


Select  a  weapons  system  or  system  modification  program  that  will  generate 
requirements  for  a  large  quantity  of  some  logistics  data  item  (such  as 
Ground  Support  Equipment  Recommendation  Data). 


Produce  and  deliver  the  required  data  items  in  the  specifid  classic,  hard¬ 
copy  form  as  prepared  from  the  LSAR  data  base. 


Simultaneous  with  (b),  implement  the  capability  for  user(s)  to  retrieve 
needed  data  from  an  on-line  data  system  through  the  use  of  terminals  located 
in  their  work  area. 


Record  and  document  the  relative  utilization  of  the  hard-copy  deliverables 
and  the  advantages  of  on-line  terminals  delivery. 


Based  upon  the  results  of  (d),  develop  specification  changes  to  require 
industry  and  DoD  components  to  move  away  from  classic  logistics  data 
items  and  towards  on-line  data  retrieval,  primarily  from  LSAR. 
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This  task  should  be  initiated  as  soon  as  possible,  preferably  during  1985,  and 
should  be  chartered  at  the  DoD  level. 

2.  Outputs  of  CALS  Demonstration  Efforts 

All  CALS  demonstration  efforts  should  result  in  capabilities  that  can  be  embodied  in 
appropriate  standards  and  data  item  descriptions  for  implementation  throughout  DoD.  Each 
demonstration  effort  should  result  in  drafts  of  the  standards  and  DIDs  that  are  appropriate 
to  its  activities. 

3.  Demonstrate  the  Digital  Delivery  of  Technical  Publications 

Technology  is  available  to  provide  multi-Service  electronic  delivery  formats  for 
technical  publications.  Integration  of  publications  requirements  with  LSAR,  provisioning 
technical  documentation  and  integration  of  the  data  with  CAE/CAD  should  be  accomplished 
to  minimize  the  number  of  interfaces  and  consequent  translating  techniques  that  industry 
and  DoD  must  maintain  for  data  delivery.  Development  of  multi-Service  electronic  delivery 
formats  will  reduce  the  number  of  translators  and  delivery  formats  required  by  both 
industry  and  the  Services.  This  activity  will  also  be  a  precursor  for  delivery  of  publications 
data  via  interactive  maintenance  aids. 

4.  Development  of  Configuration  Control  Strategy  for 

Electronic  Data  Systems 

CALS  should  be  structured  to  allow  simple  tracking  of  configuration  management 
data  by  electronic  systems.  The  development  of  engineering  and  CAD/CAM  systems  will 
include  methods  of  controlling  and  documenting  equipment  configuration.  CALS  must  be 
structured  to  utilize  this  configuration  data  and  be  expanded  to  track  and  control  the 
configuration  of  logistics  data  and  support  resource  elements  and  to  match  these  to  the 
operational  and  maintenance  hardware/software. 
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5.  Development  of  Incentives  for  Both  DoD  and  Industry 
►V  to  Move  Forward  With  CALS 


Both  industry  and  DoD  (government  agencies)  need  solid  reasons  for  adopting  the 
changes  that  will  be  required  to  fully  utilize  and  take  advantage  of  CALS.  Its  adoption, 
though  doubtlessly  very  beneficial  in  the  long  run,  will  be  costly,  inconvenient  and 
resented  by  some  whose  way  of  doing  business  will  be  upset.  The  considerations  and 
attendent  recommendations  are  as  follows: 
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Because  industry  is  profit-oriented,  recommendations  must  ultimately  result  in 
profit.  To  the  contrary,  it  will  result  in  less  absolute  dollar  value  profit,  since  a  percentage 
of  less  cost  (profit)  is  a  lesser  amount  of  money.  Therefore,  the  incentive  issue  is  not  that 
simple,  and  will  require  some  development.  Issues  that  should  be  considered  are  the  Win- 
Lose  Issue  and  the  Reduction  of  Waste  Issue. 

The  Win  or  Lose  Issue.  The  RFP  is  a  powerful  profit  incentive,  since  loss  of 
an  opportunity  for  work  is  total  loss  of  profit.  To  use  it  to  the  proper  advantage,  the 
government  must  learn  to: 

(1)  Prepare  specification  requirements  in  such  a  way  that  the  R,M&L  design 
attributes  are  unmistakenly  spelled  out  in  terms  that  a  design  engineer  can 
understand  and  relate  to. 

(2)  Prepare  quality  assurance  requirements  in  such  a  way  that  design  proof  by 
analyses  can  only  be  performed  by  computerized  techniques.  This  will 
force  their  use  in  the  design  process  as  well. 

(3)  Prepare  quality  assurance  requirements  in  such  a  way  that  test  and 
evaluation  must  make  maximum  use  of  automatically  developed  test 
procedures,  which  must  be  updated  as  a  result  of  these  tests,  and  then  be 
required  to  be  employed  in  production  acceptance  testing. 

The  Reduction  of  Waste  Issue.  In  contracts  that  have  already  been  let  as  well 
as  add-ons  and  sole-source  contracts,  there  is  no  "win-or-Iose"  issue.  Instead  there  is  the 
threat  of  profit  erosion  due  to  unexpected  problems,  overruns  from  difficult/expensive  data 
item  preparation,  and  costly  redesign  due  to  failure  to  meet  requirements  as  identified  in 
analyses  and/or  tests.  Here  incentives  will  consist  of: 

( 1 )  Improved  productivity  in  data  preparation. 

(2)  Timely  analyses  to  identify  problems  and  ensure  that  designs  can  meet 
requirements  before  the  designs  are  committed  to  drawings  and 
manufacture. 

(3)  Reduction  in  manpower,  particularly  hard  to  find  "illities"  expertise. 

Preparation  of  these  incentives  will  require  proof  that  the  computerized  techniques 
will  provide  the  above  benefits.  Credible  before-and-after  statistics  will  need  to  be 
developed  and  presented  to  industry. 
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d.  iiovernmem  Agencies  incentives 

Unlike  industry,  government  agencies  do  not  work  on  profit;  rather,  they  require 
budget  and  a  set  level  of  staff.  Staff  reduction  for  the  agencies  is  not  necessarily  an 
incentive;  nor  is  re-organization.  Therefore,  incentive  plans  must  be  developed  to  work 
within  the  framework  of  organizations,  yet  make  these  organizations  more  effective,  reduce 
the  workloads,  and  provide  for  more  accurate  results. 

It  should  be  noted  that  if  the  users  do  not  adopt,  or  take  advantage  of,  industry's 
modernization  along  the  lines  of  CALS,  the  skepticism  on  the  part  of  industry  will  grow,  as 
it  has  in  the  past,  to  once  again  defeat  the  goals  of  improved  logistics  issues. 

Directives  will  be  required,  as  will  investments  in  computers  and  in  solving  the 
standardization  issues.  One  overseeing  agency  for  coordination  must  be  established,  and 
educational  programs  begun. 

6.  Charter  a  DoD/Service  Group  That  Will  Be 

Responsible  for  Developing  and  Implementing 

Common  Data  Delivery  Formats  for  All  Services 

To  reduce  the  number  (type)  of  data  delivery  formats  required  by  the  Services,  the 
Demonstration  Group  should  be  chartered  to  review  their  demonstration  projects  and 
implement  common  data  delivery  formats  for  all  Services,  wherever  possible. 

In  addition,  an  intra-Service  coordination  committee  should  be  established,  and  a 
chairman  and  key  personnel  appointed  to  perform  the  following  tasks: 

(1)  Interact  with  the  other  Services,  DLA  and  industry  to  form  an 
oversight/coordinating  committee,  and  appoint  representatives  to  that 
committee. 

(2)  Define  specific  plans  to  implement  the  following  pilot  demonstration 
programs  as  they  relate  to  each  Service: 

a.  Automate  supportability  design-to-criteria  (Performance  R,M&L 

tradeoffs.  Safety,  and  GSE). 

b.  Automate  ILS  support  elements  using  LSAR,  i.e.,  supply  support, 
support  equipment,  T.O.s  training. 

c.  Automate  acquisition  of  logistic  support  requirements  (contractor  to 

government  to  contractor). 

d.  Logistic  data  access  and  file  transfer. 

e.  Data  audit/approval  techniques. 

f.  Structured  data  base  management  system  applications  to  CALS. 

(3)  Define  action  that  has  already  been  taken  towards  the  above. 
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Prepare  a  CALS  data/information  flow  chart  tailored  to  each  Services 
needs,  indicating  support-related  data  flows. 

Take  an  inventory  of  the  digital  data  transfer  techniques  already  in  place. 

Prepare  a  specific  plan  to  standardize  the  interfaces  between  this  Service 
and: 

a.  The  contractor 

b.  The  other  Services 

c.  NATO 

d.  DLA. 

Prepare  a  plan  for: 

a.  Specifying  and  controlling  contractor  developed  data/information. 

b.  Utilization  of  these  data/information. 


The  DoD/Services  and  DLa  should  implement  an  education  program  to  provide 
people  involved  in  CALS  with  computer/software  knowledge.  Technology  is  progressing 
very  rapidly  in  the  computer  sciences  and  must  be  understood  by  planners,  managers, 
implementees  and  operators  to  build  and  keep  CALS  viable  and  current  with  technology. 


The  overall  CALS  architecture  in  the  report  has  only  been  developed  to  the  higher 
function  levels.  The  architecture  needs  to  be  further  defined  to  the  detail  levels  required  by 
developers  and  users.  The  establishment  of  subgroups  to  further  detail  IDEF  techniques 
for  this  purpose  is  recommended. 

No  single  set  of  architectural  charts  or  flow  diagrams  will  reconcile  the  different 
(and  equally  valid)  perspectives  of  all  functional  specialists.  The  CALS  Architecture 
Subgroup's  IDEF  chart  is  but  one  model  of  logistic  information  flow  for  defining  and 
demonstrating  the  CALS  study  findings  and  recommendations,  beginning  the  process  of 
establishing  a  common  framework  for  both  industry  and  DoD  to  identify  and  communicate 
their  mutual  logistic  information  requirements.  There  is  a  need  for  improvements  in  the 
structured  process  through  which  information  processing  technology  is  applied  to  both 
acquisition  and  operational  logistics  management 
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It  is  therefore  recommended  that  the  following  tasks  be  continued  in  greater  depth 
and  detail: 

a.  Architecture  development. 

b.  Demonstration  planning,  scheduling  and  follow  up. 

c.  Development  of  incentives. 

d.  Standardization  and  specification  preparation. 


SECTION  IV:  RECOMMENDED  DEMONSTRATIONS 


A.  OVERVIEW 

This  section  contains  recommended  demonstrations  to  prove  the  feasibility  and 
cost-effectiveness  of  CALS  elements  that  are  considered  essential  to  the  whole  of  CALS 
implementation.  It  may  be  seen  from  the  following  summaries  that  the  demonstrations  are 
essentially  horizontal.  However,  each  or  all  (in  some  combination)  can  be  employed  in  the 
planned  vertical  demonstrations.  Alternately,  they  can  be  performed  in  parallel  or  ahead  of 
the  vertical  demonstrations  since  the  resulting  techniques  and  data  are  essential  to  the 
success  of  the  vertical  demonstrations.  In  addition,  these  demonstrations  are  short  and 
immediately  implementable. 


Objective:  Develop  and  demonstrate  a  tri-Service  capability  to  contractually  specify 
and  accept  delivery  of  contractor-developed  technical  publications  in  a  digital  format. 

Author:  Mark  Pittenger  -  Boeing. 


Objective:  Demonstrate  a  capability  to  design  the  prime  hardware  and  maintenance- 
aiding  diagnostics  as  an  integrated,  interactive  system.  Present  digital  maintenance 
instructions/diagnostics  to  the  technician  utilizing  a  user-friendly,  portable  display.  Show 
the  resulting  improvement  in  maintenance  of  complex  electronic  equipment  in  the  field. 


Author:  Col.  Don  Tetmeyer  -  AFHRL. 


Objective:  Demonstrate  and  document  the  benefits  of  integrating  R&M  analysis  into 
Computer-Aided  Engineering  and  Design  Systems. 


Author:  A1  Hemer  -  AFHRL. 
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4.  Automated  LSAR  Input 

Objective:  Develop  and  demonstrate  a  capability  to  input  data  automatically  to  the 
LSAR.  This  capability  will  extract  data  from  the  CAD  engineering  data  base  and  other 
automated  systems  and  load  them  directly  into  the  LSAR. 

Author:  A1  Hemer  -  AFHRL. 


5.  Automation  of  Classic  Logistic  Data  Item 

Objective:  Employ  computerized  techniques  to  prepare  a  classic  logistic  data  item 
(i.e.,  Support  Equipment  Recommendation  Summary)  in  its  presently  specified  format 
directly  from  an  LSAR  data  base.  This  will  bridge  the  gap  between  near  term  and  future 
data  acceptance,  while  at  the  same  time  demonstrate  that  all  duplication  of  effort  between 
LSAR  and  the  additional  data  items  that  are  duplicative,  but  yet  are  still  required  by  data 
users,  can  be  eliminated. 

Author:  S.  Goldstein. 


6.  Computer-Aided  Specification/RFP  Preparation 

Objective:  Demonstrate  that  reliability,  maintainability  and  supportability  equipment 
design  attributes  can  be  developed  as  part  of  a  specification's  performance  requirements  by 
computer  interaction  with,  and  prompting  of,  the  authors.  The  specification  would,  as  part 
of  an  RFP,  be  sufficiently  specific  that  the  appropriate  design  features  would  be  provided 
by  the  designer,  taking  advantage  of  the  competitive  leverage  during  the  proposal  phase. 

Author:  S.  Goldstein. 

7.  Integration  of  Demonstration  Projects 

Objective:  Demonstrate  the  ability  of  the  above  pilot  or  prototype  systems  to 
interact  and  communicate  so  that  all  logistic  functions  can  be  accomplished  with  standard 
operating  protocols  and  procedures. 

Author:  Don  Bah  an  -  AFALC. 
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B.  SPECIFIC  RECOMMENDATIONS 

Annex  3  contains  the  specific  recommendations  summarized  in  paragraph  A,  except 
Demonstration  #7  which  involved  inputs  from  the  other  subgroups  and  is  reported  in 
Volume  I,  Summary  Report,  of  this  series  of  reports. 
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CALS  FUNCTIONAL  DESCRIPTIONS 
CONTRACTOR  FUNCTIONS: 

1.  General 


Table  2-3.  IDF.F  AO  COMTRACTOR  (sheet  1  of  2) 


CONTRACTOR 

A-0  Provide  Computer  Aided  Logistics  Support 

The  purpose  is  to  describe  the  framework  of  a  Computer  Aided  Logistics 
Support  (CALS)  system  that  would  allow  DOD  to  make  full  use  of  contractor 
generated  digital  data.  The  focus  as  described  by  the  CALS  architecture 
subgroup,  is  the  automation,  standardization,  and  integration  of  the 
existing  logistics  system. 


Existing  Log  System  -  An  all  encompassing  term  denoting  the  present  way  of 
handling  the  planning,  and  data  related  to  the  design  and  acquisition 
of  support  resources,  primarily  hard  copy,  manually. 

Technology  -  Technical  issues  related  to  computerizing  all  aspects  of  design 
influence  and  logistic  support. 

Data  Requirements  -  The  data  and/or  information  required  for  design 

influence  and  the  design,  acquisition  and  preparation  of  support 
resou rces. 


DOD  Policy,  Budget,  Reqmts  -  Constraints  placed  on  the  development  and 
implementation  of  CALS  for  which  the  Government  is  responsible. 

Contractor  Capability  -  Constraints  placed  on  the  development  and 

implementation  for  which  the  contractor  is  responsible.  Primarily 
computer  resources  in-place,  IR&D  investments,  technical  ability,  etc. 

CALS  Arch  Subgroup  -  The  IDA  CALS  adhoc  subgroup  assigned  to  address 
implementation  architecture  issues. 

CALS  System  -  Computer  Aided  Logistic  Support  envisioned  as  a  system  concept 
beginning  at  the  prime  equipment  design  phase  and  ending  at  its 
obsolescence. 


Table  2-3.  IDEF  AO,  CONTRACTOR  (sheet  2  of  2) 


AO  Provide  CALS  (Contractor  functions) 


G1  ossary 

Data  Requirements  -  That  data  required  by  contract. 

DOD  -  Department  of  Defense. 

Contractor  -  The  organization  that  will  perform  to  the  contract. 

Technology  -  Technical  issues  related  to  computerizing  all  aspects  of  design 
influence  and  logistic  support. 

Design  Influence  -  Affecting  the  prime  equipment's  design  such  that  design 
features  to  specifically  address  reliability,  maintainability  and 
supportability  are  included  to  the  extent  required  to  meet  or  improve 
cont  ractual  requi rements . 

Existing  Log  Systems  -  An  all  encompassing  term  denoting  the  present  way  of 
handling  the  planning,  and  data  related  to  the  design  and  acquisition 
of  support  resources,  primarily  hard  copy,  manually. 

Resources  -  Facilities,  manpower,  capital  needed  to  perform  to  the  contract. 
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PROVIDE  CALS  (CONTRACTOR  FUNCTIONS) 


Figure  2-3-  IDEF  A1 ,  PROVIDE  LOGISTICS  MANAGEMENT,  CONTRACTOR 


Table  2-4.  IDRF  Al,  CONTRACTOR 


A1  Perform  Logistics  Management 

Glossary 

Requirements  -  Identified  needs. 

DOD  -  Department  of  Defense. 

Contractor  -  The  organization  that  performs  work  under  provisions  of  a 
contract. 

Cost  Control  -  Methodology  to  manage  program  costs. 

Schedule  Control  -  Methodology  to  manage  program  schedule. 


RFORM  LOGISTICS  MANAGEMENT,  CONTRACTOR 


IDEF  A 1 ,  CONCEPT  PAPER 
PERFORMING  LOGISTICS  MANAGEMENT 


1.  FOCUS  OF  CALS  IMPLEMENTATION 

1.1  Overview.  The  logistics  functions  which  start  at  the  time  a 
design  is  being  developed,  and  end  when  contractual  obligations 
for  the  design's  support  are  fulfilled,  are  the  responsibility  of 
a  contractor's  program/project  manager.  The  specialization  of 
the  task  usually  requires  the  delegation  of  that  responsibility 
to  an  Integrated  Logistic  Support  (ILS)  Manager  who  deals  with 
fulfilling  contractual  obligations,  scheduling,  budgeting  and 
integrating  and  general  management  of  the  subtasks  (elements)  of 
the  logistics  program.  Large  programs  may  well  have  managers  for 
each  of  the  subtasks  reporting  to  the  ILS  manager.  They  would 
perform  similar  duties  on  a  more  detailed  level.  The  subtasks 
divide  into  two  major  categories: 

a.  Categories  associated  with  the  equipment  design  effort. 
These  are  engineering  and  analytical  disciplines  such  as 
reliability,  maintainability,  testability,  etc.,  which  are 
discussed  under  IDEF  A2,  CALS  Influence  on  Equipment  Design. 

b.  Categories  associated  with  the  equipment's  support 

activities  and  support  resources,  which  are  discussed  under  the 
several  subtopics  of  IDEF  _ ,  Provide  Logistics  Support. 

The  above  categories  are  planning  on  heavy  reliance  on  CALS 
for  major  improvements  in  performing  the  many  functions  of  the 
commensurate  tasks  themselves,  as  well  as  the  vital 
information/data  flow  between  the  design,  support  and  field 
feedback  tasks.  Proper  control,  information  accuracy  and 
timeliness,  as  well  as  traceability  and  configuration 
accounting/management  is  esential  to  an  efficient  error-free 
performance  of  the  tasks  described  in  the  A2  and  A3  IDEF  topics. 
These  discuss  heavy  reliance  on  computerized  techniques  for 
information/data  preparation  and  configuration  management.  They 


also  describe  the  reliance  on  a  single  data  base  'system'  to 
ensure  proper  information/data  content  and  flow. 


The  ILS  manager  not  only  needs  to  ensure  that  the  process  is 
properly  applied  and  control  its  application,  at  least  from  a  top 
level,  but  he  also  needs  the  tools  with  which  to  accomplish  this 
control.  Presently  this  is  done  with  manual  or  computer-assisted 
budget  and  schedule  controls,  written  status  reports,  etc.  At 
best  this  is  an  inefficient  process;  at  worst  it  does  not  provide 
timely  status  or  problem  feedback  to  allow  the  best  management, 
forward  planning  and  problem  work-a-rounds  to  take  place. 


1.2  Projected  Performance  of  the  Target  System.  The 

computerized  techniques  to  be  employed  for  utilization  for  tasks 
associated  with  IDEFs  A1  and  A2  would  be  interactive  with  the 
managerial  functions  such  that  an  ILS  manager,  or  ILS  Element 
manager  could,  with  proper  access  authority,  receive  status  of 
any  element  of  design  review/status  and  support  resource 
planning,  acquisition  and  utilization.  He  could  interact  on  the 
line  with  a  computer  terminal  providing  instructions  to 
contractor  personnel  and  providing  status  and  interfacing  with 
the  customer/services  at  the  same  time.  The  computerized 
techniques  would  assist  in  schedule  preparation  and  budgeting. 
Instant  forward  planning  and  trades  regarding  spares,  personnel 
and  other  support  resource  utilization,  deployment,  stockpiling, 
changes  in  configuration,  and/or  maintenance  concepts  for 
optimization,  etc.  would  be  possible.  This  type  of  information 
would  result  in  providing  recommendations  to  the  Services  in 
ample  time  to  permit  the  most  economical  and  efficient  planning 
and  acquisition,  as  well  as  timely  changes  to  occur. 

1.3  Implementation  Considerations.  The  target  system  will 
require  that  the  major  portions  of  the  CALS  attributes  described 
in  IDEF  A1  and  A2  are  in  place.  With  that  prerequisite,  the 
implementation  of  the  appropriate  managerial  computerized 
techniques  are  minimal  at  best.  Many  standalone  managerial 
techniques  for  accounting,  scheduling  and  other  managerial  tasks 
are  readily  available  on  the  commercial  market.  These  are  also 


sufficiently  flexible  in  design  so  as  to  easily  handle  the  ILS 
tasks.  They  need  only  to  be  tied  to  the  logistics  data  base, 
which  by  design  will  permit  interfacing  and  two  way  communication 
of  information/data  and  subsequent  reports  and  feedback. 
Therefore,  implementation  should  be  relatively  simple. 

1.4  Likely  Payoffs  and  Benefits.  The  target  system  provides  the 
potential  of  properly  managing  the  'cradle  to  grave'  contractor 
responsibility  for  reliability,  supportability  and  support 
resource  planning  and  preparation  of  an  item  of  equipment,  which 
is  essential  to  the  maximum  utilization  of  the  computerized 
techniques  being  planned  for  the  actual  performance  of  the  tasks. 
Moreover  it  permits  an  interface  and/or  handover  to  the  user  of 
these  controls  and  managerial  techniques  once  he  becomes  organic. 

1.5  Changes  Needed  and  Problems .  There  are  no  specific  changes 
needed.  The  processes  of  implementing  the  CALS  will  naturally 
lead  to  the  computerizing  of  the  managerial  functions.  There  are 
no  problems  foreseen  to  accomplish  the  task. 


CALS  FUNCTIONAL  DESCRIPTIONS 
CONTRACTOR  FUNCTIONS: 

3.  IDEF  A2,  CALS  Influence  on  Equipment  Design 
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A2  Influence  Design/Modification 

This  activity  provides  design  guidance,  analyses,  and  feedback  during 
the  design  and  development  phases  of  equipment  in  order  to  achieve  design 
attributes  which  will  enhance  the  reliability,  maintainability,  and 
supportability  of  the  equipment. 

Reliability,  Maintainability,  and  Logistics  issues  in  design, 
particularly  computer  aided  design  (termed  RAMCAD)  provide  the  most 
essential  portion  of  computer  aided  logistic  support  (CALS),  in  that  they 
provide  a  design  that  is  tailored  and  optimized  not  only  from  the  standpoint 
of  readiness  and  availability  but  also  from  supportability. 

The  products  resulting  from  the  computerized  techniques  also  provide 
the  information  necessary  for  logistics  support  planning,  for  the 
preparation  of  technical  manuals,  the  defining  and  optimization  of  spares 
procurement  and  placement,  the  technical  requirements  for  test  and  other 
support  equipment,  as  well  as  the  test  procedures,  the  built-in-test 
routines,  and  all  the  data  necessary  for  the  LSAR. 

The  process  must  take  place  during  the  active  design  phase  prior  to 
the  release  of  drawings  or  design  information  for  the  manufacture  of  the 
equipment.  In  order  to  be  as  successful  as  possible,  the  task  would  require 
meaningful  lessons  learned  feedback  and  comparison  system  information  from 
the  government.  The  maintenance  concept,  supportability  specification, 
target  support  costs  and  the  related  portion  of  the  performance  requirements 
provided  by  the  government  would  need  considerable  improvement  from  the 
manner  in  which  these  are  specified  today. 

Design  rules  in  terms  of  reliability,  maintainability,  safety  and 
human  factors  information  stored  in  libraries  would  have  to  be  updated  to 
reflect  the  present  technology,  and  stores  in  a  means  that  would  be 
accessible  by  computer  techniques.  This  would  require  changes  on  the  part 
of  the  developer  as  well  as  the  government.  Computerized  design  and 
analytical  techniques  must  be  made  to  interact,  or  at  least  communicate, 
which  presently  presents  considerable  technical  problems.  The  data 
collection  and  feedback  system  must  be  improved. 


CONTRACTOR/ 1 9/ A2, 1  I  TITUi  INFLUENCE  OC$I9N/HOOIFICATION 


Table  2-6.  IDRF  A?  ,  CONTRACTOR  (sheet  1  of  3) 


A2  Influence  Oesign/Modifi cation  (Con't) 

Five  activities  describe  the  design/modification  influence.  The  first 
of  these  is  the  provision  for  design  guidance.  This  activity  translates  the 
Reliability,  Maintainability  and  Supportability  requirements  of  an  equipment 
into  terms  that  can  be  related  to  the  designer  in  terms  of  guides,  to  his 
computer  in  terms  of  rules  for  rules  checking,  the  quantitative  portions  of 
design  rules  and  analytical  goals  in  terms  of  figures  of  merit,  as  well  as 
provide  a  library  of  information  for  use  by  the  design  and  analyses 
programs. 

The  second  activity  is  the  performance  of  allocations.  This  task 
provides  the  equipment  division  or  partitioning  guidance  to  the  design  and 
allocates  the  Reliability,  Maintainability  quantitative  requirements  to  the 
modules  so  partitioned.  It  also  provides  a  library  of  parts  for  use  by  the 
design  and  performs  tradeoffs  between  Reliability,  Maintainability  and 
Supportability  issues. 

Equipment  design  is  the  third  activity.  This  is  the  process  which 
results  in  the  information  necessary  to  build  the  equipment.  The  target 
system  would  provide  for  completely  interactive  design  guidance,  analyses 
and  feedback,  as  well  as  for  automatic  optimization  between  trades  of 
reliability,  maintainability,  supportability,  mechanical /electrical 
packaging  and  modularization,  performance,  weight,  volume  and  cost. 

The  fourth  activity  is  the  performance  of  analyses.  The  analytical 
techniques  employ  performance  and  design  information  as  derived  from 
drawings,  performance  specifications,  timing  diagrams,  interconnection 
diagrams,  etc.  This  activity  prepares  the  Reliability,  Maintainability, 
Testability,  Human  Factors,  Safety,  Transportability,  and  Optimum  Repair 
Level  Analyses  of  the  design. 


The  last  activity  is  the  support  of  trades.  The  term  trades 
connotates  the  sacrifice  of  one  attribute  for  the  enhancement  of  another. 
Unless  all  attributes  remain  within  their  specified  limits,  then  the 
government  must  define  the  degrees  of  freedom  that  are  allowed  in  these 
trades.  It  is  assumed  that  these  will  be  provided  in  the  future  and  that 
they  will  include  more  than  just  the  support  cost  alternatives  that  are 
presently  allowed  in  that  they  will  permit  trade  between  size,  weight,  and 
performance.  Presently  trades  are  performed  utilizing  life  cycle  cost 
modelling  and  risk  modelling. 


Glossary 


Maintenance  Concept  -  Equipment  specification  and/or  maintenance  scenario 
analyses  at  a  higher  level. 


Supportability  Specification  -  Specifications  derived  from  supportability 
requi rements. 


Target  Support  Costs  -  Projected  support  costs  supplied  by  certain 
contractual  documents. 


Performance  Requirements  -  Those  requirements  implied  by  design 
specifications. 
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^able  2-6.  IDEF  A2,  CONTRACTOR  (sheet  2  of  3) 

A2  Glossary  (Con't) 

Comparison  System  -  The  predecessor  system  upon  which  the  present  design  is 
based.  It  will  also  contain  lesson  learned. 

Lessons  Learned  Feedback  -  Field  experience  data  reduced  to  cause  and  effect 
of  problems. 

Design  Rules  -  Contractor  support  engineering  design  principles  related  to 
R,  M  &  L. 

Guidance  Conference  -  Customer  contractor  interface  meeting. 

Supportability  Requirements  -  Specified  quantitative  and  qualitative 
requi rements. 

Specified  Techniques  -  Analytical  techniques  performed  in  accordance  with  a 
contractually  specified  process. 

Manual  -  Performed  manually  as  opposed  to  computerized. 

RLA  -  Repair  level  analysis.  Determines  the  most  cost  effective  repair 
level  of  an  item. 

Schedules  -  Time  frames  specified  by  the  Contract  Statement  of  Work. 

Costs  -  Monetary  restrictions  specified  by  the  Contract  Statement  of  Work. 

Design  Reviews  -  Feedback  of  design  analyses  by  the  customer. 

Performance  Information  -  Specifications,  tolerances,  etc.  as  recorded 
during  test  procedures. 

Design  Information  -  Digital,  pictorial,  and  text  information  used  as  input 
to  Automated  Authoring  Systems  for  T.O.'s,  test  procedures,  LSAR, 
spare  buys  decision  documents,  and  contractor  support  engineering 
data. 

CAE/CAD/CAM  -  Computer  aided  engineering,  design,  manufacturing  techniques 
as  owned  by  the  contractor  or  provided  as  Government  Furnished 
Equipment  (GFE). 

RAMCAD  -  Reliability,  maintainability,  and  logistics  issues  in 

computer-aided  design  as  owned  by  the  contractor  or  provided  as  GFE. 

Figures  of  Merit  -  Quantifiers  of  an  attribute  (ie  MTBF  for  reliability). 

Validations  -  Manual  inputs  from  review  of  the  analyses  and/or 
demonstrations. 

Support  Resources  -  The  items  of  support  equipment  tools,  technical  manuals, 
manpower,  etc.  necessary  to  support  and  maintain  on  equipment. 

Reports,  Data,  Procedures  -  Input  to  Automated  Authoring  Systems  for  T.O.'s, 
test  procedures,  LSAR,  spare  buys  decision  documents,  and  contractor 
support  engineering  data. 
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Table  2-6.  IDRF  A2,  CONTRACTOR  (sheet  3  of  3) 


A2  Glossary  (Con't) 


Defined  Degrees  of  Freedom  -  Permissible  excursions  from  norms,  for  use  in 
trade-offs  supplied  by  the  Contractual  Statement  of  Work  and/or  ILS 
Conference. 

LCC  -  Computerized  Life  Cycle  Cost  analyses  techniques  as  specified  by  the 
government  with  fixed  constants  provided  by  the  government. 

Schedule  Risk  Assessment  -  Contractor  in-house  developed  techniques  to 
assess  risk  in  meeting  schedules. 

Performance  Risk  Assessment  -  Contractor  in-house  developed  techniques  to 
assess  risk  in  complying  with  performance  requirements. 

Readiness/Sustainability  Assessment  -  Computerized  model  as  developed  by  the 
contractor  or  supplied  GFE  with  which  to  project  the  degree  of  system 
readiness  and  operational  sustainability. 

Transportability  -  Computerized  model  as  developed  by  the  contractor  or 
supplied  GFE. 
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Table  2-7.  (Sheet  1  of  3) 

DATA  CONNECTIVITY  INDEX  FOR  THE  DESIGN  IDEF  CHART 


INFORMATION  INPUT 


FROM  OR  TO 


Comparison  System 
Lessons  Learned  Feedback 
Design  Rules 

INFORMATION  OUTPUTS 


Data  Collection  and  Feedback  Systems 
Data  Collection  and  Feedback  Systems 
Software  Library  or  Independent  Pgm 


Performance  Information  Automated  Authoring  Systems  for 

T.O.  (i.e.,  Specification  and 
Tolerances )Test  Procedures 
LSAR 


Design  Information 


Analyses  Reports,  Data  and 
Procedures 


Automated  Authoring  Systems  for 
T.O. 

Test  Procedures 
LSAR 

Spares  Buys  Decision  Documents 
Contractor  Support  Engineering  Data 

Automated  Authoring  Systems  for 

T.O. 

Test  Procedures 
LSAR 

Spares  Buys  Decision  Documents 
Contractor  Support  Engineering  Data 


CONTROLS 

Maintenance  Concept  Equipment  Specification  and/or 

Maintenance  Scenario  Analyses  at  a 
Higer  Level 

Supportability  Specification  Equipment  Specification  and/or 

Maintenance  Scenario  Analyses  at  a 
Higher  Level 


Target  Support  Costs 


Contractual  Documents 


Performance  Requirements 


Design  Specifications 


Table  2-1.  (Sheet  2  of  3) 

DATA  CONNECTIVITY  INDEX  FOR  THE  DESIGN  IDEF  CHART 


INFORMATION  INPUT 


FROM  OR  TO 


CONTROLS  (Continued) 

Specified  Analytical 
Techniques 

Schedules 


Contract  Statement  of  Work 


Contract  Statement  of  Work 


Costs 


Contract  Statement  of  Work 


Design  Reviews 


Feedback  of  Design  Analyses  by 
the  Customer 


Validations 


Support  Resources 


Manual  inputs  from  Review  of  the 
Analyses  and/or  Demonstrations 

Contractual  Statement  of  work 
and/or  ILS  Conference 


Defined  Degrees  of  Freedom 


Contractual  Statement  of  Work 
and/or  ILS  Conference 


MECHANISMS 


Guidance  Conference 


Customer  Contractor  Interface 
Meeting 

Computerized  Techniques  as 
Specified  by  the  Customer  (the 
Computerized  Model  is  usually 
either  specified  or  given  to  the 
Contractor) 


CAE /CAD/CAM 


RAMCAD 


Computerized  Techniques  as  owned 
by  the  Contractor  or  provided  as 
Government  Furnished  Equipment 

Computerized  Techniques  as  owned 
by  the  Contractor  or  provided  as 
Government  Furnished  Equipment 
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Table  2-7.  (Sheet  3  of  3) 

DATA  CONNECTIVITY  INDEX  FOR  THE  DESIGN  IDEF  CHART 


INFORMATION  INPUT  FROM  OR  TO 

MECHANISMS  (Continued) 

LCC  Computerized  Life  Cycle  Cost 

Analyses  Techniques  as  specified 
by  ti  e  Government  with  fixed 
constants  provided  by  the 
Government.  The  technique  is  either 
provided  by  the  Government  or 
specified 

Schedule  Risk  Assessment  Contractor  in-house  developed 

technique 

Performacne  Risk  Assessment  Contractor  in-house  developed 

technique 

Readiness  Sustainability  Computerized  Model  as  developed 

by  the  Contractor  or  supplied  GFE 


Transportab i 1 i ty 


Computerized  Model  as  developed 
by  the  Contractor  or  supplied  GFE 


I DBF  A2,  DESCRIPTION 
CALS  INFLUENCE  ON  EQUIPMENT  DESIGN 


1.  DESIGN  INFLUENCE 

a.  Current  Status:  Presently  the  analytical  techniques 

employed  are  performed  in  series  with  a  design,  where  feedback 
becomes  costly  in  terms  of  design  changes  and  schedule  slippages. 

b.  Target  System  Characteristics:  This  task  provides 

design  guidance,  analyses,  and  feedback  during  the  design  and 
development  phases  of  an  equipment  in  order  to  achieve  design 
attributes  which  will  enhance  the  reliability,  maintainability, 
and  supportability  of  the  equipment. 

c.  Benefits :  Reliability,  Maintainability,  and  Logistics 

issues  in  design,  particularly  computer-aided  design  (termed 
RAMCAD),  provide  the  most  essential  portion  of  computer-aided 
logistic  support  (CALS),  in  that  they  provide  a  design  that  is 
tailored  and  optimized  not  only  from  the  standpoint  of  readiness 
and  availability  but  also  from  supportability.  The  products 
resulting  from  the  computerized  techniques  also  provide  the 
information  necessary  for  logistics  support  planning,  for  the 
preparation  of  technical  manuals,  the  defining  and  optimization 
of  spares  procurement  and  placement,  the  technical  requirements 
for  test  and  other  support  equipment,  as  well  as  the  test 
procedures,  the  built-in-test  routines,  and  all  the  data 
necessary  for  the  LSAR. 

In  addition,  if  feedback  were  provided  while  a  design  is 
being  prepared,  design  enhancements  which  may  improve  RM&S 
well  beyond  what  is  specified  will  not  affect  cost,  schedule  or 
performance  of  the  equipment.  To  the  contrary,  it  may  even 
improve  these  because  the  analytical  techniques  employed  would 
discover  design  problems,  input/output  mismatches,  manufacturing 
and  test  problems,  etc.  The  techniques  would  also  provide  the 
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most  authoritative  and  useful  products  for  the  logistic  support 
planning  and  resources. 

d.  Problems :  The  process  must  take  place  during  the 

active  design  phase  prior  to  the  release  of  drawings  or  design 
information  for  the  manufacture  of  the  equipment.  In  order  to  be 
as  successful  as  possible,  the  task  would  require  meaningful 
lessons  learned  and  feedback  and  comparison  system  information 
from  the  government.  The  maintenance  concept,  supportabi lity 
specification,  target  support  costs  and  the  related  portion  of 
the  performance  requirements  provided  by  the  government  would 
need  considerable  improvement  from  the  manner  in  which  these  are 
specified  today.  Design  rules  in  terms  of  reliability, 
maintainability,  safety  and  human  factors  information  stored  in 
libraries  would  have  to  be  updated  to  reflect  the  present 
technology,  and  stored  in  a  means  that  would  be  accessible  by 
computer  techniques.  This  would  require  changes  on  the  part  of 
the  developer  as  well  as  the  government.  Computerized  design  and 
analytical  techniques  must  be  made  to  interact,  or  at  least 
communicate,  which  presently  presents  considerable  technical 
problems.  The  data  collection  and  feedback  system  must  be 
improved . 

e.  Implementation  Approach:  There  is  no  single  input  or 

single  analytical  technique  that  can  achieve  the  desired  results. 
The  various  inputs  and  analyses  (typical  analyses  are  provided  in 
Table  2-10)  are  interdependent,  as  shown  in  the  lower  IDEF  level 
charts.  This  requires  the  development  of  either  interactive 
techniques  or  a  rapid,  error  free  means  of  transferring  data  from 
one  program  to  the  other  so  as  to  provide  a  reasonable  cycle  of 
analyses  and  feedback.  To  be  effective,  this  cycle  should  take 
no  longer  than  it  takes  to  test  the  performance  adequacy  of  the 
evolving  design;  anywhere  from  a  few  minutes  to  two  days. 

The  rapid  development  of  independent  analytical  computerized 
techniques  for  design  assistance  and  analyses  would  indicate  that 


a  two  step  process  for  implementation  is  the  most  feasible  at 
this  time.  The  first  step  would  be  to  develop  the  means  to 
communicate  between  the  various  programs;  and  the  second  step 
would  be  to  make  them  interactive. 

f.  Implementation  Cost:  Very  high. 

1.1  DESIGN  GUIDANCE 

a.  Current  Status:  Presently  much  of  this  is  done 

manually  by  the  Reliability,  Maintainability  and  Supportab i  1  ity 
engineers  as  part  of  the  LSA  process.  Requirements  are  given  the 
designer  by  indoctr inat ions  or  written  design  guides.  However, 
inputs  are  generally  limited  to  what  is  contained  in  the 
specification  and  the  illities  engineers’  own  experience. 

b.  Target  System  Characteristics:  This  task  translates 

the  Relaibility,  Maintainability  and  Supportabi lity  requirements 
of  an  equipment  into  terms  that  can  be  related  to  the  designer  in 
terms  of  guides;  to  his  computer  in  terms  of  rules  for  rules 
checking;  the  quantitative  portions  of  design  rules  and 
analytical  goals  in  terms  of  figures  of  merit;  as  well  as 
providing  a  library  of  information  for  use  by  the  design  and 
analyses  programs. 

c.  Benefits :  This  is  the  first  step  in  tailoring  a 

design  to  make  it  fit  the  support  and  maintenance  concept 
required  by  the  user. 

d.  Problems :  To  be  effective,  the  Reliability, 

Maintainability  and  Supportability  portions  of  a  design 
specification  must  contain  requirements  which  were  properly 
tailored  and  allocated  to  the  equipment  from  the  overall 
maintenance  and  support  concept  by  the  government.  Quantitative 
requirements  concerning  built-in-test,  testability,  etc.  would  be 
ranked  in  the  order  of  importance,  and  tied  to  specific 
performance  attributes.  Field  data  collection  systems  would 


be  more  effective,  and  the  information  contained  in  a 
computerized  library,  which  could  be  remotely  accessed  with 
search  and  sort  modes  available.  As  shown,  a  guidance  conference 
at  the  very  beginning  of  a  program  is  an  essential  mechanism  to 
the  success  of  design  guidance. 

e.  Implementation  Approach:  The  translation  of  the 

requirements  to  the  necessary  outputs  requires  expert  subjective 
opinion  and  therefore  must  remain  a  manual  task  performed  by 
experienced  illities  engineers.  The  computerized  output 
products,  however,  must  be  provided  in  such  fashion  that  they  are 
accessible  to  the  computer-aided  design  program  as  well  as  the 
computerized  analytical  techniques  which  will  be  employed.  This 
would  require  the  same  development  strategy  of  communications 
technique  previously  mentioned. 

f.  Implementation  Cost;  Very  high. 

1.2  ALLOCATIONS 

a.  Current  Status:  Presently  this  task  is  performed 

manually  using  computerized  stand-alone  programs  such  as  the 
Repair  Level  Analyses  and  Life  Cycle  Cost  Models. 

b.  Target  System  Characteristics:  This  task  provides  the 

equipment  division  or  partitioning  guidance  to  the  design  and 
allocates  the  Reliability,  Maintainability  quantitative 
requirements  to  the  modules  so  partitioned.  It  also  provides  a 
library  of  parts  for  use  by  the  design  and  performs  tradeoffs 
between  Reliability,  Maintainability  and  Supportabi lity  issues. 

c.  Benefits:  This  task  provides  the  design-to-goals  or 

Figures  of  Merit  (FOMs)  to  be  contained  in  the  LSAR. 
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P  rob lems : 


None 


e.  Implementation  Approach:  The  task  requires  expert 

judgment.  It  should  therefore  remain  primarily  a  manual  task, 
utilizing  computer  techniques  only  as  tools  to  generate  the 
information  needed  to  make  the  judgment. 


Implementation  Cost: 


None . 


1.3  EQUIPMENT  DESIGN 

a.  Current  Status:  Presently  the  design  process  is 

evolving  into  one  which  employs  computer  techniques  to  assist  the 
designer  in  attaining  the  performance  (CAE),  in  rendering  the 
drawings  (CAD),  and,  if  automated,  machine  tool  information 
(CAM).  It  is  assumed  that  this  process  will  continue  to  be 
enhanced  to  the  point  where  it  will  be  universally  utilized  in 
such  manner  that  the  design  programs  could  directly  interact  or 
provide/accept  information  from  analytical  programs  which  are 
involved  with  the  performance  of  the  item  being  designed.  This 
would  be  the  collection  of  programs  termed  RAMCAD.  Presently  the 
analytical  techniques  are  performed  without  such  interaction  even 
though  they  may  use  stand-alone  computerized  techniques  that  are 
available  today  to  perform  most  of  the  analyses  required  by 
Reliability,  Maintainability,  and  Supportabi lity  (See  Table  2- 
8). 

b.  Target  System  Characteristics:  This  is  the  process 

which  results  in  the  information  necessary  to  build  the 
equipment.  The  target  system  would  provide  for  completely 
interactive  design  guidance,  analyses  and  feedback,  as  fcell  as 
for  automatic  optimization  between  trades  of  reliability, 
maintainability,  supportability,  mechanical/electrical  packaging 
and  modularization,  performance,  weight,  volume  and  cost. 


c.  Benefits :  This  task  provides  for  the  influencing  of  a 

design  such  that  its  reliability,  maintainability,  supportability 


Table  2-8.  (Sheet  1  of  5) 

LIST  OF  R,  M,  AMD  L  DESIGN-RELATED  ANALYTICAL  TECHNIQUES 


1 

1.1 

1.1.1 

1.1.2 

1.2 

1.2.1 

1 .2.1.1 

1.2. 1.2 

1.2. 1.3 


NAME 


REFERENCE 


RELIABILITY  ANALYSES: 

Parts  failure  rate  catalogue  for 
allocations  and  worst  case 
analyses 

Lessons  learned  failure  rate 
feedback  to  modify  1.1 

Mission  thermal,  mechanical 
stress  profile  for  application 
in  catalogue  search 

Reliability  Predictions 


Basic  prediction  from  parts  application, 
packaging  and  function  configuration 
of  the  design 


MIL -ST  D-1 388-1 A ,  Tasks  301 
MIL-HDBK-217 


MIL -ST  D-1 388-1 A  501.2 


MIL -ST  D-1 388-1 A  301.2.4 


MIL -ST  D-785  Task  203 
MIL -STD-756 
MIL-HDBK-217 

MIL-ST  D-785  Task  203 
For  use  in  F  ME  C  A  and 
MIL-ST  D-1 388-2A  Data 
Record  B 


Circuit  analyses  to  determine 
electrical  stresses  under  operating 
conditions  to:  (1)  modulate  1.2.1, 
and  (2)  identify  overstresses 

Circuit  Analysis  to  determine 
thermal  stresses  under  operating 
conditions  to:  (1)  modulate  1.2.1, 
and  (2)  identify  overstresses 

Construction  analysis  to  determine 
physical  stresses  under  operating 
conditions  to:  (1)  modulate  1.2.1, 
and  (2)  identify  overstresses 


1.2.2 


Mission  reliability  prediction 
based  on  functional  block  diagram, 
mission  profiles,  operational 
scenarios,  redundancies,  work-a-rounds, 
degradations,  etc. 

1.2.3  Construction  of  reliability  block 
diagra  m  for  use  in  other  analyses 
such  as  FMECA,  BIT  and  Test  Point, 
LSA  R,  etc. 

1.3  F  ailure  M  odes,  E  ffects  and 
Criticality  Analysis 


1.3- 1  Functional  Block  Diagram  of  the 

item  under  analysis  for  use  in  the 
FMECA,  m  attainability  analysis,  LS  A  R 
and  technical  manuals 

1.3.2  Failure  Modes  and  Effects  Analysis 
Hardware  approach 

1. 3- 2.1  Top  down  technique 

1 .3- 2.2  Bottom  up  technique 

1.3- 3  Failure  Modes  and  Effects  Analysis 

F  unctional  approach 

1 .3- 3-1  Top  down  technique  (preferred  for 

later  use  in  BIT,  Test  Point, 

M attainability  and  Maintenance 
Task  analyses,  as  well  as  t  developtg 
fault  isolation  strategies) 

1. 3- 3-2  Bottom  up  technique 

1.3- M  Some  combination  of  1.3.2  and  1.3-3 

1.3- 5  Criticality  Analysis 


MIL-STD-785  Task  203 
For  use  in  FMECA  and 
MIL -ST  D-1 338-2A  Data 
Record  B 


MIL -STD-785  Task  203 
F  or  use  in  F  M  E  C  A  and 
MIL -ST  D-1 388-2  A  Data 
Record  B 

MIL -ST  D-785  Task  204 
MIL -ST  D-1 338-1 A ,  Task 
301.2.4.1 

MIL -ST  D-1 629,  Task  101 
4.1.4 


MIL -ST  D-1 629,  Task  101 


MIL -ST  D-1629,  Task  102 


Table  2-8.  ($heet3of5) 

LIST  OF  R,  M,  AND  L  DESIGN  RELATED  ANALYTICAL  TECHNIQUES 


p 

'■J  ' 

NAME 

L->. 

1.3.5. 1 

Qualitative  approach 

m 

1. 3.5.2 

Quantitative  approach 

rS* 

1. 3.5.3 

Construction  of  Criticality  Matrix 

1.3.6 

F  M  E  C  A  M  attainability  Inf  or  m  ation 

1 

This  would  require  the  combining 

of  other  analytical  results  such  as 
from  BIT  and  Test  Point  analyses 

k. 

1.4 

Sneak  Circuit  A  nalyses 

Also  for  input  to,  or  use  in, 

r 

BIT  and  Test  Point  Analyses, 

Testability  analysis,  construction 

of  test  procedures,  etc. 

1.5 

Electronic  Parts/ Circuit 

Tolerance  Analysis 

m 

For  use  in  design  evaluation,  risk 

analysis  and  reliability  prediction 

1.6 

Reliability  Centered  Maintenance 

1.7 

Parts  Control 

K 

>> 

*»v. 

1.7.1 

Design  guides  including  junction 

O 

temperatures  allowed,  derating 

| 

requirements,  parts  application, 
margins  of  safety,  etc. 

* 

1.7.2 

Identification  of  R  eliability 

Critical  Items 

fc: 

m 

1.8 

Reliability  Risk  Analysis 

REFERENCE 


MIL -ST  D-1 629,  Task  103 


MIL -ST  D-785,  Task  205 


MIL-STD-785,  Task  206 


MIL -ST  D-1 388-1 A ,  Task 
301  ?  li  ? 

MIL-STDI785,  Task  209 

MIL-ST  D-785,  Task  207 
MIL -ST  D-1 38-1 A ,  Task  301 


MIL-ST  D-785,  Task  208 


MIL-ST  D-1 388-1  A,  Task 
301.2.3 
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Table  2-8.  (Sheet Hof 5) 

LIST  OF  R,  M,  AND  L  DESIGN  RELATED  ANALYTICAL  TECHNIQUES 


NAME 


REFERENCE 


2  MAINTAINABILITY  ANALYSES: 

2.1  Elemental  maintenance  actions 
catalogue  including  maintenance 
times  and  skills 

2.2.1  Lessons  learned  feedback  for 
task  times  and  difficulties 

2.2.2  Maintenance/use  profile  input 
to  adjust  elemental  task  times 
and  skills 

2.2  Maintenance  access  analysis 

2.3  Operating  and  Maintenance  Task 
A  nalysis 

For  inputs  to  the  Maintainability 
prediction,  technical  manuals  and 
LSAR 

2.4  Maintainability  Prediction 


2.4.1  MIL-HDBK-472,  Procedure  1 

2.4.2  MIL-H  DBK-472,  Procedure  2 

There  are  many  adaptations  of  this 
procedure.  Its  the  m  ost  rigorous 

2.4.3  MIL-H  DB  K-472,  Procedure  4 

2.4.4  A  RIN  C  Fault  Symptom  Model 

2.5  Built-in-Test  Analysis 

For  use  in  design  analysis, 
integrated  diagnostics  trades, 
Operational  A  variability  predictions 
LSA  R,  etc. 


MIL -ST  D-1 388-1 A ,  Tasks  300 

MIL -ST  D-1 388-1 A ,  Task 
300.2.4 

MIL-H  DBK-472 

MIL -ST  D-1 388-1 A ,  Task  501.2 


MIL -ST  D-1 338-1 A ,  Task 
301.2.4 


MIL -STD-280 

MIL -ST  D-1 388-1 A ,  Task 
301.2.4.3 


MIL -STD-470 
MIL-HDBK-472 


RA  DC-TR -70-89 

MIL -ST  D-1 388-1 A ,  Task 
301.2.4 
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Table  2-8 .  (Sheet  5  of  5) 

List  of  R,  M,  and  L  Design  Related  Analytical  Techniques 


NAME 


REFERENCE 


Testability  A  nalysis  MIL-ST  D-1 388-1 A ,  Task 

Used  for  design  analysis,  test  301.2.4 

point  placement 

U  U  T  Com  patibility  w  ith  auto  m  atic  MIL  -S  T  D  -207 6 

test  equipment.  For  use  in  design 

analysis,  integrated  diagnostics 

trades,  preparation  of  test  requirements, 

LSA  R,  etc. 

Test  time  analysis  MIL-H  DBK-472 

ITEMS  FOR  INTEGRATED  LOGISTICS  TASKS 

Level  of  R epair  A  nalyses  MIL-ST  D-1 388-1 A ,  Tasks  303 

Life  Cycle  Cost  Analyses  MIL-ST  D-1 388-1 A ,  Tasks  303 

Integrated  Diagnostics  Tradeoff  MIL-ST  D-1 388-1  A,  Tasks  303 

D  esign  Interf  ace  Com  patibility 
Check 

Check  on  connector  pin  assignments  vs 
signal  na  m  es,  signal  types  and 
signal  tolerances.  For  checking  designs 
(for  interfacing),  inputs  to  support 
equipment,  test  and  calibrations 
requirements,  and  inputs  to 
Technical  Manuals 

Check  on  signal  nam es  from  signal  origin 
to  destination  through  the  signal  flow 
diagrams  as  well  as  the  schematics.  For 
design  analysis  and  Technical  Manuals  source 
Material  accuracy  check 


and  readiness  related  design  attributes  are  optimally  included  in 
the  design  features.  This  task  also  provides  the  generation  and 
communication  of  performance  information  required  for  preparation 
of  technical  manuals  as  well  as  the  electrical/mechanical  design 
information  for  that  same  purpose.  It  could  provide,  if  properly 
structured,  the  parts  lists  required  for  spares  planning  data,  as 
well  as  the  illustrated  parts  breakdown,  and  also  provide  the 
pictorial  information  necessary  for  technical  manuals  and 
illustrated  parts  breakdowns.  It  could  also  provide  a 
transcription  of  the  specified  performance  requirements  in  such 
manner  that  it  can  be  used  for  the  LSAR ,  as  well  as  the 
descriptive  portion  of  a  technical  manual. 

d.  Problems :  The  programs  employed  for  designing  an 

equipment  generally  interact  with  the  programs  for  preparing  a 
drawing  or  preparing  the  digital  information  from  which  to 
manufacture  an  item.  This  results  in  the  ultimate  information 
being  in  a  format  that  is  not  readily  usable  by  text  processors, 
or  analytical  techniques  which  require  quantities  such  as 
dimensions,  voltages,  waveforms,  timing  diagrams,  etc.,  from  the 
field  of  a  drawing. 

e.  Implementation  Approach:  A  three  step  approach  is 
recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  rapidly  available,  with  no 
manual  transcription  required.  The  second  step  could  also 
provide  for  developing  Government  furnished  programs  that  may  be 
made  available  to  suppliers  who  can  not  afford  to  develop  or 
purchase  their  own.  The  third  step  would  be  to  develop  the 
technique,  or  interfacing  Executive,  to  make  the  various  programs 
interactive . 


f 


Implementation  Cost:  Very  high. 


1.4  ANALYSES 


a.  Current  Status;  Presently  the  analytical  techniques 
employ  performance  and  design  information  as  derived  from 
drawings,  performance  specifications,  timing  diagrams, 
interconnection  diagrams,  etc.  Techniques  employed  are  those 
listed  in  Table  2-8,  many  of  which  are  already  available  in 
computerized  techniques  from  software  houses,  as  well  as  in¬ 
house-developed  programs.  Manual  techniques  are  also  used, 
especially  in  cases  where  subjective  analyses  as  well  as  mock-ups 
are  utilized,  such  as  in  human  factors  and  safety  analyses. 

b.  Current  Status:  This  task  prepares  the  Reliability, 

Maintainability,  Testability,  Human  Factors,  Safety, 
Transportability,  and  Optimum  Repair  Level  Analyses  of  the 
design. 

c.  Benefits:  The  final  output  of  the  analyses  provides 

the  instrument  for  design  approval.  Depending  on  contractual 
requirements  this  can  vary  from  the  comparison  of  the  results  of 
the  analysis  with  the  allocations,  or  to  performing  a 
demonstration  of  the  attribute  being  analyzed,  such  as  the  MTBF 
for  Reliability. 

The  output  of  the  analyses  also  provides  all  of  the  data 
that  are  necessary  for  the  LSAR.  They  could  also  provide  the 
test  program  sets  for  use  of  automatic  test  equipment,  the  built- 
in-test  routines  with  which  to  program  the  built-in-test 
computer,  training  material,  detailed  step-by-step  procedures  for 
assembly/disassembly,  and  similar  repair  actions.  Detailed 
timing  diagrams  and  test  point  signatures  can  also  be  provided. 
The  Repair  Level  Analyses  are  also  the  trades  necessary  to 
optimize  the  repair  facilities,  spares  buys  and  placement,  and 
transportation  issues. 


d.  Problems :  Inputs  to  the  analyses  require  translation 
of  information  from  the  fields  of  drawings  or  contents  of 
digitized  design  information  in  such  a  manner  that  they  are 
useful  for  calculations  and  text  processing.  Programs  to  perform 
this  type  of  translation  are  not  available  yet,  though  the 
problem  is  being  addressed  in  standardization  specifications  such 
as  IGES.  Presently  this  transition  is  performed  manually  and  is 
subject  to  high  cost,  long  lead  times,  long  reaction  times,  and 
considerable  error. 

e.  Implementation  Approach:  A  three  step  approach  is 

recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  rapidly  available,  with  no 
manual  transcription  required.  The  second  step  would  be  to 
develop  analytical  techniques  that  are  required,  but  not 
considered  to  become  available  in  the  near  future.  The  second 
step  coula  also  provide  for  developing  government  furnished 
programs  that  may  be  made  available  to  suppliers  who  can  not 
afford  to  develop,  or  purchase  their  own.  The  third  step  would 
be  to  develop  the  technique,  or  interfacing  Executive,  to  make 
the  various  programs  interactive. 

f.  Implementation  Cost:  Very  high. 


1.5  TRADES 


Current  Status: 


The  term  trades  connotates  the 


sacrifice  of  one  attribute  for  the  enhancement  of  another. 

Unless  all  attributes  remain  within  their  specified  limits,  the 
government  must  define  the  degrees  of  freedom  that  are  allowed  in 
these  trades.  It  is  assumed  that  these  will  be  provided  in  the 
future  and  that  they  will  include  more  than  just  the  support  cost 
alternatives  that  are  presently  allowed,  in  that  they  will  permit 
trade  between  size,  weight,  and  performance.  Presently  trades 
are  performed  utilizing  life  cycle  cost  modeling  and  risk 
modeling. 
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b.  Target  System  Characteristics:  This  task  provides  for 

optimizing  Reliability,  Maintainability,  Supportability,  and 
other  design  attributes.  Future  trades  would  also  use  these 
models  with  final  decisions  being  made  by  expert  judgment. 

Future  trades,  however,  would  also  model  readiness  and 
sustainability,  as  well  as  the  effects  on  transportability.  The 
latter  should  be  modeled  in  such  a  way  as  to  interact  with  the 
modularization  of  the  equipment  being  designed,  which  in  turn 
would  interact  with  provisioning  costs,  stocking  levels,  and 
warehousing  considerations. 

c.  Benefits :  The  process  of  trades  is  one  of 

optimization  between  equipment  design  features  for  Reliability, 
Maintainability  and  Supportability  versus  the  capability  and  cost 
of  the  support  resources.  As  such  it  is  the  key  to  the  process 
that  determines  the  cost  and  features  in  the  equipment  being 
supported,  versus  the  cost  of  features  of  the  resources  necessary 
to  support  that  equipment. 

d.  Problems:  To  be  effective,  trades  require  accurate 

user  inputs  as  concerns  the  application  of  equipment,  its 
maintenance  scenario,  the  desired/available  support  equipment, 
skills,  and  training  limitations,  as  well  as  the  government 
supplied  input  quantifiers  for  the  life  cycle  cost  modeling. 

These  all  have  to  accurately  fit  the  situation  being  modeled  and 
must  include  the  proper  overhead  costs,  otherwise  the  results  of 
the  model  would  always  be  skewed  towards  government  labor 
intensive  support,  and  be  highly  inaccurate.  The  reason  for  this 
inaccuracy  is  that  all  other  (non-labor)  comparisons  are  made  on 
the  basis  of  actual  cost  to  the  government. 

e.  Implementation  Approach:  Trades  require  the 

interaction  of  the  results  of  the  many  analytical  models 
discussed.  The  recommended  approach  therefore  is  to  complete  the 
communications  capability  of  these  models,  and  in  parallel 
develop  an  expansion  of  a  universally  applicable  life  cycle  cost 
model  that  can  trade  the  various  issues  in  terms  of  relatable 


or  equivalent  cost  factors.  When  that  is  completed,  the 
automatic  interaction  of  these  models  should  be  developed.  It 
should  also  be  considered  that  both  stages  of  development  can  be 
accomplished  in  several  steps,  adding  the  simpler  trades,  namely 
those  that  are  readily  equatable  to  cost,  first,  and  then 
applying  expertise  judgment/ranking  to  the  remainder,  while 
evolving  the  entire  technique.  In  this  manner,  individual  layers 
of  sophistication  could  be  demonstrated  separately  and  their 
accuracy  and  utility  validated  and  evaluated  more  readily. 

f .  Implementation  Costs:  High 

1.6  DEMONSTRATE  AND  APPROVE 

a.  Current  Status:  The  demonstration,  or  validation  of 

compliance  with  specified  Reliability,  Maintainability,  and 
supportability  requirements  is  usually  performed  on  actual 
equipment  using  manual  techniques.  Occasionally  it  may  consist 
of  evaluating  the  analytical  results  which  were  used  to  prove 
compliance,  but  that  too  is  a  manual  task. 

The  subtasks  associated  with  the  task  requires  the 
development  of  test  procedures,  the  actual 

validation/demonstration  and  the  assimilation  of  test  results. 

The  preparation  of  test  procedures  is  the  only  task  with  a 
relatively  high  potential  for  application  of  computerized 
techniques . 


b.  Target  System  Characteristics:  As  the  testability 

analyses  programs  become  more  sophisticated,  the  development  of 
checkout  and  fault  isolation  procedures  will  follow  as  a  natural 
output  of  these  analyses.  This  could  provide  for  automated 
preparation  of  test  programs  for  automatic  test  equipment,  the 
BIT,  as  well  as  for  preparation  of  step-by-step  procedures  to  be 
used  in  technical  .  unuals.  A  number  of  limited  (in  analytical 


complexity)  programs  are  already  available.  These  programs  would 
then  also  be  required  to  be  used  in  equipment  validation/ 
demonstration.  Test  results  could  also  be  compared  to  the 
results  expected  as  derived  from  the  testability  analyses.  This 
would  be  computerized,  but  since  it  is  a  relatively  simple  yet 
objective  task,  it  would  remain  to  be  best  performed  manually. 
Computerized  techniques  could  compare  the  configuration  and 
source  of  the  information  of  the  various  analyses  to  be  combined 
so  as  to  make  that  traceability/cataloging  easier  for  the  final 
analyst . 

c.  Benefits:  The  test  procedures,  fault  isolation 

procedures  and  procedures  for  repair  sections  employed  in  the 
validation/deraonstration  are  normally  specified  to  be  included  in 
the  technical  manuals,  or  at  least  form  a  significant  technical 
input  to  them.  Normally,  however,  the  scheduling  is  such  that 
this  does  not  happen.  The  use  of  computerized  techniques  for  the 
preparation  of  that  material  will  make  it  available  at  the  time 
of  design  release  completely  eliminating  this  problem,  and 
enabling  the  proper  preparation  of  training  material,  technical 
manuals,  checkout  send  fault  isolation  procedures,  and  support 
equipment  recommendations.  Computerized  assimilation  of 
validation/demonstration  results  (as  well  as  assembly  line 
testing)  will  provide  instant  feedback,  enabling  timely 
correction  of  any  procedural  errors. 

e.  Implementation  Approach:  A  three  step  approach  is 

recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  rapidly  available,  with  no 
manual  transcription  required.  The  second  step  would  be  to 
develop  analytical  techniques  that  are  required,  but  not 
considered  to  become  available  in  the  near  future.  The  second 
step  could  also  provide  for  developing  Government  furnished 
programs  that  may  be  made  available  to  suppliers  who  can  not 
afford  to  develop  or  purchase  their  own.  The  third  step  would 


be  to  develop  the  technique  or  interfacing  Executive  to  make  the 
various  programs  interactive. 


Implementation  Cost: 


Low . 


1 .6.1 


START  DIAGNOSTIC  PROCEDURES 


a.  Current  Status:  This  task  has  usually  been  performed 

manually,  since  it  is  based  on  the  design  requirements  rather 
than  firm  design  information. 


b.  Target  System  Characteristics:  This  is  a  rough  cut 

procedure  for  fault  detection  and  fault  isolation.  Prior  to 
performing  any  other  trades,  modern  electronic  design  is 
structured  to  result  in  functional  packaging  in  order  to 
facilitate  fault  detection  and  fault  isolation,  as  well  as  to 
minimize  the  number  of  signals  that  have  to  enter  and  leave  a 
module,  since  this  interrelation  between  modules  would  then 
naturally  occur  at  functional  nodes.  (Functional  packaging 
limits  commonality.) 

In  the  future,  manual  techniques  are  also  envisioned  to  be 
best  suited  for  this  judgmental  process,  because  it  requires 
knowledge  of  overall  performance,  signal  flows,  and  feasible 
divisions  into  nodes.  The  outputs  are  also  best  left  in  written 
format,  since  most  of  the  allocation  process  will  be  subjective 
and  employ  manual  techniques. 

c.  Benefits :  This  process  results  in  the  equipment 

partitioning  and  the  allocation  of  FOMs  which  will  ultimately  be 
entered  into  the  LSAR.  The  partitioning  will  determine  the 
modularization,  standardization,  testing,  repair,  transportation, 
etc.  attributes  of  the  equipment  and  its  modules. 

d.  Problems:  None. 


Implementation  Approach:  None. 


f.  Implementation  Cost:  None. 


1.6.2 


EQUIPMENT  PARTITIONING 


a.  Current  Status:  The  Information  regarding  the  test 

nodes  and  ambiguities  resulting  from  the  diagnostic  procedure  are 
normally  provided  in  hard  copy  for  review  by  a  senior  level 
engineer.  The  task  usually  involves  tradeoffs  which  are 
technical  in  nature  as  concerns  the  division  by  nodes,  mechanical 
in  nature  as  concerns  the  amount  of  circuitry  that  can  be  placed 
within  the  module  being  designed,  the  cause/effect  information 
available  from  the  RLA,  and  the  trades  of  task  1.6.4.  This  task 
is  performed  manually,  with  computerized  techniques  assisting  in 
the  mathematics  of  the  tradeoffs,  such  as  the  RLA. 

b.  Target  System  Characteristics:  This  task  provides  the 

division  of  an  equipment  or  an  assembly  into  its  next  lower  level 
of  assembly.  It  utilizes  the  test  node  information  from  the 
diagnostic  procedure,  as  well  as  the  RLA  to  perform  this  task. 

The  model(s)  would  automatically  optimize  between  division  for 
the  sake  of  testability  (functional),  packaging  and 
transportability,  cost  (standardization  and  multi-application), 
performance,  etc.  as  part  of  the  design  process. 

c.  Benefits:  This  process  results  in  the  equipment 

partitioning  and  the  allocation  of  FOMs,  which  will  ultimately  be 
entered  into  the  LSAR.  The  partitioning  will  optimize  the 
modularization,  standardization,  testing,  repair,  transportation, 
etc.  attributes  of  the  equipment  and  its  modules  between 
performance  and  supportability  considerations. 


d.  Problems :  This  process  requires  the  development  of 

the  proper  cost  factors  as  for  Trades,  paragraph  1.5. 


e.  Implementation  Approach:  Same  as  1.5. 

f.  Implementation  Cost;  Same  as  1.5. 

1.6.3  RELIABILITY  ALLOCATION 

a.  Current  Status;  The  technique  utilizes  a  parts 
library  for  MIL-HDBK-217  based  predictions,  as  well  as  inputs 
from  GUIDEP's  data  base.  Presently  the  task  involves  a  mix  of 
manual  and  computerized  techniques,  with  the  latter  normally 
associated  with  just  the  parts  assignment  and  search  of  the 
GUIDEP  files. 


b.  Target  System  Characteristics:  This  task  provides  the 

allocated  MTBF  to  the  module  as  it  has  been  partitioned,  as  well 
as  narrowing  the  selection  of  preferred  parts  to  be  used  in  the 
design  of  the  module.  The  search  of  the  parts  library  as  it  is 
done  today  could  possibly  be  improved  in  that  the  process  of 
designing  a  performance  of  an  item  could  very  well  narrow  down 
the  range  of  parts  that  could  provide  that  performance,  and  with 
that  precondition  could  save  a  considerable  amount  of  time. 

Also,  if  done  properly,  the  precondition  and  subsequent  parts 
selection  could  result  in  the  parts  listing  to  be  contained  on 
the  drawing's  bill  of  material  automatically,  as  well  as  be 
provided  in  text  processor  format  for  use  in  editing  into  parts 
lists  and  LSAR  inputs. 

c.  Benefits :  This  task  results  in  the  selection  of 

components  for  use  in  the  equipment  design,  LSAR  H  sheets,  as 
well  as  the  allocated  MTBF  for  use  in  the  LSAR  A  sheet. 

d .  Problems :  There  are  no  problems  anticipated  with  the 

library  function,  since  many  programs  already  exist  that  can  do 
this.  The  design  interactive  portion,  however,  needs  the  same 
development  as  the  analytical  techniques  previously  discussed . 


e. 


Implementation  Approach:  A  two  step  approach  is 

recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  available  rapidly,  with  no 
manual  transcription  required.  The  second  step  would  be  to 
develop  the  technique,  or  interfacing  Executive,  to  make  the 
various  programs  interactive. 

f.  Implementation  Cost:  Low. 

1.6.4  TRADES 

a.  Current  Status;  Presently  trades  are  performend  using 
life  cycle  cost  modeling  and  risk  modeling.  Future  trades  would 
also  use  these  models,  but  with  the  final  decisions  being  made  by 
expert  judgment. 

b.  Target  System  Characteristics:  This  task  provides  for 

optimizing  Reliability,  Maintainability,  Supportabi lity ,  Design 
and  Maintenance  Concepts  during  the  allocation  process.  Future 
trades,  however,  would  also  model  readiness  and  sustainability, 
as  well  as  the  effects  on  transportability.  The  latter  would  be 
modeled  in  such  a  way  as  to  interact  with  the  equipment 
partitioning  or  modularization  of  the  equipment  being  designed, 
which  in  turn  would  interact  with  the  maintainability  allocations 
and  reliability  allocations. 

c.  Benefits :  The  process  of  trades  is  one  of 

optimization  between  equipment  design  features  for  Reliability, 
Maintainability  and  Supportabi lity  versus  the  capability  and  cost 
of  the  support  resources.  As  such,  it  is  the  key  to  the  process 
that  determines  the  cost  of  features  in  the  equipment  being 
supported,  versus  the  cost  of  features  of  the  resources  necessary 
to  support  that  equipment.  See  also  1.5. 


d.  Problems ;  To  be  effective,  trades  require  accurate 
user  inputs  as  concerns  the  application  of  equipment,  its 
maintenance  scenario,  the  desired/available  support  equipment, 
skills  and  training  limitations,  as  well  as  the  government 
supplied  input  quantifiers  for  the  life  cycle  cost  modeling. 
These  all  have  to  accurately  fit  the  situation  being  modeled  and 
must  include  the  proper  overhead  costs,  otherwise  the  results  of 
the  model  would  always  be  skewed  towards  government  labor 
intensive  support  and  be  highly  inaccurate.  The  reason  for  this 
inaccuracy  is  that  all  other  (non-labor)  comparisons  are  made  on 
the  basis  of  actual  cost  t_o  the  government. 

e.  Implementation  Approach:  See  1.5. 

f .  Implementation  Cost;  High. 

1.6.5  MAINTAINABILITY  ALLOCATIONS 

a.  Current  Status:  The  technique  utilizes  the  allocated 

MTBF  to  allocate  repair  times  in  inverse  proportion  to  failure 
rates,  wherever  possible.  Task  time  estimates  are  input  from 
guides  such  as  MIL-HDBK-472 .  Presently  the  task  is  performed 
manually.  The  mathematics  are  relatively  simple  and  judgment  is 
required  in  those  cases  where  adjustments  have  to  be  made  to  the 
allocation  to  truncate  resulting  low  repair  times  for  realism, 
and  high  repair  times  so  as  not  to  exceed  specified  maximum 
repair  times.  Computerized  techniques  would  speed  the  process 
somewhat,  but  is  not  essential  for  this  task. 


b.  Target  System  Characteristics:  This  task  provides  the 

allocated  MTTR  to  the  module  as  it  has  been  partitioned.  It  also 
serves  to  separate  task  times  between  testing  tasks,  remove  and 
replace  tasks,  and  repair  tasks.  As  such  the  task  results  in  the 
first  identification  of  skills,  manpower  requirements,  and  repair 
times  for  use  in  the  LSAR  and  training  plans. 


d. 


Problems : 


The  task  requires  interpretation  of  the 
supportabi lity  requirements  as  well  as  a  determination  of  how  to 
handle  the  ambiguities  that  have  been  identified  in  the  early 
diagnostic  procedures.  This  requires  expert  judgment  and 
therefore  a  hard  copy  information  transfer  for  the  analyses  of 
this  information.  This  would  indicate  that  at  best  computer 
techniques  could  be  used  in  assisting  the  analyst  only  in  the 
mathematical  portions  of  this  process,  until  such  time  as  the 
interactive  portions  of  the  partitioning  program  are  developed. 

e.  Implementation  Approach;  It  is  recommended  that  the 
present  procedure  continue  as  is  until  the  partitioning 
programs(s)  has  been  developed.  The  maintainability  allocations 
would  then  be  one  of  its  outputs. 

f.  Implementation  Cost:  There  is  no  cost  peculiar  to 

this  implementation. 

1.6.6  FI PST  CUT  FMECA 

a.  Current  Status:  The  technique  uses  conceptual  design 

information  and  the  translated  supportabi lity  requirements.  As 
such  is  requires  expert  judgment  and  is  performed  manually. 

b.  Target  System  Characteristics;  This  task  tests  the 
equipment  partitioning  from  a  standpoint  of  assessing  the  effect 
and  propagation  of  functional  failures.  It  identifies  problems 
in  performance  degradation,  fault  detection,  fault  isolation,  as 
well  as  critical  failures  and  parts.  Its  function  in  the 
allocation  process  is  primarily  one  of  optimizing  the  equipment 
partitioning,  identifying  potential  design  problems,  and 
attempting  to  prevent  the  use  of  critical  components  and 
circuits.  There  are  digital  techniques  available,  but  these  are 
usually  used  when  design  information  is  available  during  the 
analytical  process. 


c. 


Benefits : 


This  task  is  part  of  the  optimization 
process  during  the  allocation  of  Reliability  and  Maintainability 
quantifiers,  as  well  as  the  equipment  partitioning.  It  is 
therefore  a  key  element  in  the  development  of  design  features  to 
enhance  Reliability,  Maintainability  and  Supportability . 


d.  Problems :  None. 

e.  Implementation  Approach:  None. 

f.  Implementation  Cost:  None. 


1.6.7  RELIABILITY  STRESS  ANALYSES 

a.  Current  Status;  Presently  the  analyses  are  performed 
with  stand-alone  modules  of  computerized  techniques,  which  are 
available  either  off-the-shelf  or  as  in-house  developed.  Except 
perhaps  for  small  companies,  very  few  of  these  analyses  are 
performed  manually  today. 


b.  Target  System  Characteristics;  This  task  analyzes  a 
proposed  design  to  determine  the  effect  of  stress  on  the 
performance  and  reliability  of  that  design.  The  analysis 
requires  detailed  design  information.  Electrical  design  and 
component  information  is  required  to  perform  electrical  stress 
analyses.  The  electrical  stress  analyses  apply  to  parts  location 
information.  Ambient/cooling  air  information  is  required  for 
thermal  stress  analyses.  An  environmental  profile,  together  with 
mechanical  layout  and  packaging  information,  is  required  to 
perform  environmental  stress  analyses,  which  could  range  from 
temperature  and  mechanical  shock  to  vibration  and  other 
mechanical  stresses  on  the  components,  as  well  as  the  chassis  or 
circuit  board  upon  which  these  are  mounted.  The  assumption  is 
that  all  this  information  will  be  available  to  the  analytical 
techniques  of  the  future,  such  that  these  analyses  could  be 
performed  interactively  with  a  CAE/CAD  program. 


c.  Benefits:  Properly  applied,  the  results  of  these 

analyses  can  become  a  major  contributor  towards  improving 
reliability  of  a  design.  The  results  also  provide  the  updated 
Reliability  predictions  which  are  utilized  in  the  Maintainability 
Analyses  and  the  LSAR. 

d.  Problems:  Inputs  to  the  analyses  are  derived  directly 

from  schematics  and  mechanical  drawings.  However,  the 
information  that  is  required  by  these  techniques  is  the  technical 
content  of  these  drawings  rather  than  the  pictorial 
representation.  This  could  very  well  provide  a  problem  in 
communicating  from  a  CAD  prepared  drawing,  in  which  the 
information  is  digitized  in  the  form  of  a  pictorial  rather  than 
an  information  content.  Interacting  directly  with  the  program 
that  prepares  schematics  or  mechanical  layouts  may  present 
another  problem  in  that  off-the-shelf  software  that  prepares 
drawings  may  not  have  the  provision  to  interact  with  an 
analytical  program.  Environmental  requirements  are  normally  FOMs 
as  provided  from  the  performance  information,  and  therefore  could 
be  applied  directly  as  inputs  to  the  analyses.  Equally,  the 
allocations  should  present  no  problems  for  inputting.  The  output 
of  the  stress  analyses,  as  concerns  component  placement,  should 
also  interact  with  the  mechanical  drawing  software,  otherwise 
that  software  would  have  to  be  entered  again  manually  to  change 
the  original  layout.  This  could  be  time-consuming  and  prone  to 
error. 

e.  Implementation  Approach:  A  three  step  approach  is 

recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  available  rapidly,  with  no 
manual  transcription  required.  The  second  step  would  be  to 
develop  analytical  techniques  that  are  required,  but  not 
considered  to  become  available  in  the  near  future.  The  second 
step  could  also  provide  for  developing  Government  furnished 
programs  that  may  be  made  available  to  suppliers  who  can  not 
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afford  to  develop,  or  purchase  their  own.  The  third  step  would 
be  to  develop  the  technique  or  interfacing  Executive  to  make  the 
various  programs  interactive. 


1.6.8  TESTABILITY  ANALYSES 

a.  Current  Status:  Presently  the  analyses  are  performed 

by  both  manual  and  automated  techniques.  Manual  techniques  are 
used  where  a  sufficient  library  of  components  is  not  available  to 
perform  these  techniques  automatically,  or  where  the 
specifications  are  sufficiently  liberal  so  that  a  simple 
checklist  such  as  may  be  found  in  MIL-STD-2076  would  suffice. 

Very  powerful  analytical  techniques  exist  today.  These  require 
inputs  in  the  form  of  the  schematic  and,  as  a  minimum,  the  range 
of  input  test  stimuli.  The  programs  that  analyze  performance 
also  require  the  desired/specified  transfer  characteristics  of 
the  circuit  in  order  to  assess  its  capability  to  perform  that 
function. 


b.  Target  System  Characteristics:  This  task  analyzes  a 

circuit  to  determine  whether  or  not  it  is  testable  for  all  its 
performance  attributes  with  the  test  facilities  that  are  resident 
in  the  circuit.  There  are  two  major  approaches  to  this.  One  is 
a  by-product  of  a  circuit  analyses  for  purposes  of  determining 
its  capability  to  perform  its  intended  function,  which  is 
sometimes  labeled  a  sneak  circuit  analyses  or  circuit  performance 
analyses.  The  other  is  a  purely  statistical  technique.  The 
statistical  technique  will  only  provide  a  figure  of  merit, 
whereas  the  detailed  analyses  will  actually  provide  information 
for  test  point  placement  as  well  as  the  development  of  fault 
isolation  procedures. 

c.  Benefits ;  This  task  provides  for  the  testability 

aspects  of  the  equipment  being  designed.  It  also  provides  the 


information  necessary  to  develop  the  test  procedures,  fault 
isolation  procedures,  and  built-in-test  routines.  When  properly 
structured,  these  could  be  developed  into  technical  manual 
information,  as  well  as  the  actual  test  procedures  to  be  used  by 
the  support  equipment. 

d.  Problems :  The  input  requirements  rre  very  much  the 

same  as  for  the  Reliability  Stress  Analyses  in  that  technical 
information  content  of  a  schematic  is  require^.  Depending  on  the 
circuit  complexity  and  component  fan-outs,  a  program  can  take 
several  hours  to  run.  To  be  effective,  time  must  be  scheduled 
for  that  assessment  such  that  feedback  and  corrective  action  in  a 
design  process  can  take  place. 

e.  Implementation  Approach:  A  three  step  approach  is 

recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  available  rapidly,  with  no 
manual  transcription  required.  The  second  step  would  be  to 
develop  analytical  techniques  that  are  required  but  not 
considered  to  become  available  in  the  near  future.  The  second 
step  could  also  provide  for  developing  Government  furnished 
programs  that  may  be  made  available  to  suppliers  who  can  not 
afford  to  develop  or  purchase  their  own.  The  third  step  would  be 
to  develop  the  technique,  or  interfacing  Executive,  to  make  the 
various  programs  interactive. 

f.  Implementation  Cost:  Low. 

1.6.9  FMECA 

a.  Current  Status:  Presently  there  is  software  available 

either  off-the-shelf  or  contractor-developed  to  perform  these 
analyses  on  relatively  complex  equipment.  The  software,  however, 
requires  manual  inputs  to  it.  The  information  that  the  program 
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utilizes  should  be  readily  available  from  the  Reliability  Stress 
Analyses  and  Testability  Analyses  in  a  format  suitable  for 
direct  input. 


b.  Target  System  Characteristics:  This  task  provides  the 

failure  modes,  effects  and  criticality  analyses  of  the  item  being 
designed,  as  well  as  its  next  higher  level  of  assembly  from 
inputs  provided  to  it  automatically  from  the  design  process,  and 
the  results  of  the  reliability  and  testability  analyses. 

c.  Benefits :  The  task  sets  priorities  in  utilization  of 

test  facilities,  which  will  determine  the  arrangement  of  test 
procedures,  built-in-test  routines,  Ma intainab i 1  i ty  and 
Maintenance  Tasks  Analyses. 

d.  Problems :  None. 

e.  Implementation  Approach?  Since  many  models  already 
exist,  only  the  communications  and  interaction  with  other 
programs  need  to  be  developed.  However,  this  development  is  part 
of  the  modernizing  of  the  analyses  programs  and  therefore  needs 
no  special,  peculiar  attention. 


>lementation  Cost: 


None . 


1.6.10  TRANSPORTA JIL IT Y  AND  REPAIR  LEVEL  ANALYSES 

a.  Current  Status:  The  analytical  techniques  are  well 

specified  in  military  standards  and  handbooks,  and  are  simple 
enough  to  be  performed  manually,  as  is  presently  done.  The  RLA 
modeling  has  used  computerized  techniques  for  many  years.  There 
are  a  considerable  amount  of  models  available  to  do  this.  All  of 
the  models,  however,  require  manual  input  to  them.  The  outputs 
are  printouts  and  summaries.  The  inputs  are  primarily  numeric  in 
nature  and  could  readily  be  available  from  digitized  outputs  of 
Maintainability,  Reliability,  and  appropriate  design  information. 


b.  Target  System  Characteristics:  Transportability 

issues  have  rarely  played  a  major  role  in  the  partitioning  of  an 
equipment.  This  is  due  to  the  fact  that  in  most  situations  the 
transportability  cost  factors  are  an  extremely  low  part  of  life 
cycle  costs.  However,  they  could  be  significant  for  delicate 
equipment  or  equipment  that  requires  frequent  overhaul  at  remote 
locations.  It  is  envisioned  that  an  output  of  this  analyses 
could  be  digitized  in  such  manner  as  to  be  interactive  with  the 
RLA  and  the  partitioning  analyses.  The  RLA  in  turn  seeks  to 
ascertain  the  most  economical  maintenance  and  maintenance  level 
of  the  item  in  question.  It  uses  life  cycle  cost  modeling  with 
which  to  test  the  cost  effectiveness  of  each  maintenance  concept 
evaluated,  including  that  of  discard.  The  target  system  would 
provide  for  automatic  inputting  to  the  model,  as  well  as  its 
interaction  with  the  other  models  described  under  Trades, 
paragraph  1.5. 

c.  Benefits :  This  task  analyzes  the  handling  and 

transportation  requirements  of  an  item  of  equipment.  It  is 
usually  limited  to  the  assembly  and  sub-system  level. 
Transportation  factors  are  a  direct  input  to  the  LSAR.  The  RLA 
is  an  essential  determinant  for  system  division,  standardization 
among  modules  and  the  planning  for  support  resources.  The 
results  of  the  RLA  are  also  a  direct  input  to  the  LSAR  and  the 
maintenance  codings  of  the  spares  lists. 


d.  Problems:  The  same  problems  of  developing  the 

interactive  techniques  as  for  other  analyses  apply  here.  This 
interaction  with  other  analytical  techniques  needs  to  be 
developed.  This  interaction,  however,  will  be  part  of  the 
development  of  the  other  techniques  and  will  not  require  any 
peculiar  attention  for  this  task. 

e.  Implementation  Approach:  A  three  step  approach  for 

the  transportability  analysis  is  recommended.  The  first  would  be 


to  provide  for  communication  between  the  presently  available 
design  assistance  and  analyses  programs  such  that  information  is 
rapidly  available  with  no  manual  transcription  required.  The 
second  step  would  be  to  develop  analytical  techniques  that  are 
required,  but  not  considered  to  become  available  in  the  near 
future.  The  second  step  could  also  provide  for  developing 
Government  furnished  programs  that  may  be  made  available  to 
suppliers  who  can  not  afford  to  develop  or  purchase  their  own. 
The  third  step  would  be  to  develop  the  technique,  or  interfacing 
Executive,  to  make  the  various  programs  interactive.  No  special 
implementat ion  is  required  for  the  RLA  because  it  will  be  a 
fallout  of  developing  other  analytical  technique  interfaces. 


Implementation  Cost: 


Low . 


1.6.11 


MAINTAINABILITY  ANALYSES 


a.  Current  Status:  Presently  this  task  is  performed 

primarily  utilizing  manual  techniques,  with  assistance  by 
computers  or  calculators  to  do  the  mathematics. 

b.  Target  System  Characteristics :  This  task  prepares  the 

Maintainability  Analyses  of  a  design.  The  final,  detailed 
Maintainability  Analyses  require  input  from  the  Reliability 
Analyses,  the  Testability  Analyses,  the  Test  Procedures,  the 
FMECA  and  design  information  in  terms  of  the  assembly,  cabling, 
assembly  process,  components  and  component  placements,  fasteners, 
nomenclatures,  and  reference  designators.  Feedback  from  the 
Repair  Level  Analysis,  if  performed,  is  also  required.  Since  the 
mathematics  are  relatively  simple,  it  is  assumed  that 
computerized  techniques  interactive  with  an  analyst  should  be 
possible  in  the  very  near  future  to  facilitate  this  task. 

c.  Benefits :  The  output  of  this  task  results  in  the  MTTR 

prediction,  as  well  as  the  elemental  task  times  and  skills  that 
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are  necessary  to  perform  equipment  repair.  These  are  direct 
inputs  to  the  LSAR  or,  if  so  provided,  the  validation 
requirements  of  the  contract. 

d.  Problems ;  Inputs  to  the  analyses  require  translation 
of  information  from  the  fields  of  drawings  or  contents  of 
digitized  design  information  in  such  manner  that  they  are  useful 
for  calculation  of  the  elemental  tasks  involved  in  maintenance. 
This  technology  is  not  yet  available,  although  standardization 
specifications  such  as  IGES  address  the  requirements.  The 
elemental  tasks  on  the  other  hand  present  no  problem  since  they 
are  usually  derived  from  a  handbook  ana  could  very  well  be 
contained  in  a  computerized  library. 


e.  Implementation  Approach:  A  three  step  approach  is 

recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  rapidly  available,  with  no 
manual  transcription  required.  The  second  step  would  be  to 
develop  analytical  techniques  that  are  required  but  not 
considered  to  become  available  in  the  near  future.  The  second 
step  could  also  provide  for  developing  government  furnished 
programs  that  may  be  made  available  to  suppliers  who  can  not 
afford  to  develop  or  purchase  their  own.  The  third  step  would  be 
to  develop  the  technique,  or  interfacing  Executive,  to  make  the 


various  programs  interactive. 


Implementation  Cost: 


None . 


1.6.12 


HUMAN  FACTORS  AND  SAFETY  ANALYSES 


a.  Current  Status:  This  task  is  normally  performed 

manually  prior  to  a  drawing  release,  or  shortly  thereafter.  This 
task  is  based  on  the  rules  available  from  military  specification 
and  handbooks  and  could  therefore  become  a  CAE/CAD  available  rule 


library;  at  least  for  the  straightforward  "good  design  practices" 
design  checking.  It  is  assumed  that  eventually  this  will 
automatically  become  part  of  electrical  and  mechanical  CAR.  If 
so,  this  would  leave  the  anthropometr i c  analyses,  which  are 
presently  in  development. 

b.  Target  System  Characteristics!  This  analyses  will 
automatically  analyze  the  design  from  the  standpoint  of  work 
access  and  other  anthropometric  considerations.  It  will, 
together  with  the  Maintainability  Analyses,  determine  the  task 
and  skill  requirements,  as  well  as  training  requirements  of  the 
maintainer  and  operator.  Since  the  Safety  Analyses  are  closely 
linked  to  the  Human  Factors  Analyses  and  ascertain  dangerous 
voltages,  power  levels,  hazardous  tasks,  sharp  edges,  toxic 
material,  etc.  they  would  become  an  interactive  part  of  the  human 
factors  analyses. 

c.  Benefits :  The  analyses  provides  for  design 

incorporation  of  human  factors  and  safety  features.  The  output 
of  this  task  also  determines  the  skill  levels,  training 
requirements,  safety  equipment,  number  of  people  per  task,  etc. 
which  are  a  direct  input  to  the  LSAR,  as  well  as  the  technical 
manuals . 

d.  Problems:  The  task  requires  inputs  as  to  the  physical 

makeups  and  clearances  of  a  design.  It  also  requires  information 
ragarding  the  voltages,  power  levels,  toxic  and  hazardous 
materials,  handles,  dials,  knobs,  etc.  This  is  usually  evaluated 
manually  by  inspection  of  drawings  and  would  now  require  being 
translated  into  digitized  points  and  vectors,  which  is  natural  to 
computer-aided  drafting  as  well  as  computerized  analytical 
techniques.  In  addition,  the  output  needs  to  be  in  a  format 
compatible  with  text  processing  for  the  descriptive  material  to 
be  used  in  technical  manuals,  and  a  format  compatible  with 
numeric  manipulation  for  the  LSAR.  Both  of  these  requirements 
need  some  technical  development  similar  to  that  required  for  the 
reliability,  maintainability  and  testability  analyses. 


e.  Implementation  Approach;  A  three  step  approach  is 
recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  rapidly  available  with  no 
manual  transcription  required.  The  second  step  would  be  to 
develop  analytical  techniques  that  are  required  but  not 
considered  to  become  available  in  the  near  future.  The  second 
step  could  also  provide  for  developing  government  furnished 
programs  that  may  be  made  available  to  suppliers  who  can  not 
afford  to  develop  or  purchase  their  own.  The  third  step  would  be 
to  develop  the  technique,  or  interfacing  Executive,  to  make  the 
various  programs  interactive. 


>lementation  Cost;  High. 


1.6.13  DEVELOPMENT  OF  PROCEDURES 

a.  Current  Status:  Present  software  programs  that  can 

perform  this  task  are  limited  in  much  the  same  manner  as  the 
Testability  Analyses  programs  are.  Much  of  this  work  therefore 
is  still  done  utilizing  manual  techniques,  which  are  based 
primarily  on  Acceptance  Test  Procedures  used  on  the  shop  floor. 

b.  Target  System  Characteristics;  This  task  develops  the 
checkout,  fault  isolation,  alignment,  and  procedures  to  be  used 
by  the  built-in-test  routine,  as  well  as  the  support  equipment 
and  technical  manuals.  As  the  testability  analyses  programs 
become  more  sophisticated,  the  development  of  checkout  and  fault 
isolation  procedures  will  follow  as  a  natural  output  of  these 
analyses.  This  could  provide  for  automated  preparation  of  test 
programs  for  automatic  test  equipment — the  BIT,  as  well  as  for 
preparation  of  step-by-step  procedures  to  be  used  in  technical 
manuals.  A  number  of  limited  (in  analytical  complexity)  programs 
are  already  available. 


c.  Benefits :  The  output  of  this  task  is  an  essential 

input  to  the  training  and  technical  manual  preparation,  as  well 
as  to  the  selection  of  support  equipment,  and  preparation  of  test 
and  fault  isolation  procedures. 

d.  Problems :  No  prob lems  are  env isioned  because  the 

inputs  to  this  process  are  the  same  as  the  outputs  of  the 
Testability  Analyses,  and  should  therefore  present  very  little 
difficulty  in  automatic  transfer  of  information  from  one  program 
to  the  other,  or  total  interaction  of  the  programs. 

e.  Implementation  Approach:  A  three  step  approach  is 

recommended.  The  first  would  be  to  provide  for  communication 
between  the  presently  available  design  assistance  and  analyses 
programs  such  that  information  is  rapidly  available  with  no 
manual  transcr ipt ion  required.  The  second  step  would  be  to 
develop  analytical  techniques  that  are  required  but  not 
considered  to  become  available  in  the  near  future.  The  second 
step  could  also  provide  for  developing  Government  furnished 
programs  that  may  be  made  available  to  suppliers  who  can  not 
afford  to  develop  or  purchase  their  own.  The  third  step  would  be 
to  develop  the  technique,  or  interfacing  Executive,  to  make  the 
various  programs  interactive. 


f.  Implementation  Co3t;  Low. 

1.6.14  VALIDATION/DEMONSTRATION 

a.  Current  Status;  This  task  consists  of  those 
validations  or  demonstrations  required  by  the  individual 
contract.  It  normally  assesses  both  the  accuracy  and  validity  of 
the  analyses  performed  and  then,  if  required,  performs  a 
demonstration(s)  of  Reliability,  Maintainability,  etc.  The 
demonstrat ions  are  always  performed  manually  on  real  equipment. 

If  only  a  validation  is  required,  it  is  normally  performed  by 
review  of  the  results  of  the  various  analyses.  This  task 


is  usually  performed  by  supervisory  personnel,  peer  level 
engineers,  or  customer  representatives. 


Target  System  Characteristics: 


Because  there  is  no 


direct  relation  to  CALS  except  that  the  task  is  usually  a 
prerequisite  to  the  release  and  utilization  of  the  information 
resulting  from  the  analyses  during  the  design  process,  there  is 
no  reason  to  automate  it.  Nor  does  this  task  lend  itself  to  yet 
another  level  of  digitized  analyses. 


1.6.15 


ASSIMILATE  ANALYSES  RESULTS 


a.  Current  Status?  This  task  is  performed  manually.  The 
analyst  is  normally  a  high  level  illities  engineer  or  engineering 
manager  whose  approval  is  also  normally  requisite  to  the  output 
reports . 

b.  Target  System  Characteristics:  Computerized 

techniques  could  compare  the  configuration  and  source  of  the 
information  of  the  various  analyses  to  be  combined,  so  as  to  make 
that  traceability/cataloging  easier  for  the  final  analyst.  This 
task  would  have  to  remain  essentially  a  manual  review  and 
assimilation  of  the  material  generated. 


Benefits : 


This  task  collects  and  assimilates 


Reliability,  Maintainability,  and  Supportability  analyses  results 
and  checks  for  consistency  among  them.  It  results  in  the  final 
reports  which  are  normally  required  by  a  contract  and,  if 
necessary,  provides  a  coding  system  that  ties  the  analyses  to  the 
equipment  configuration.  The  release  of  this  assimilated 
information  is  controlled  by  its  approval  process  via  the 
validation/deraonstration,  task  1.6.14. 

This  task  is  also  the  final  gate  through  which  outputs  of 
the  various  analytical  techniques  must  pass  in  order  to  input  to 
the  LSAR,  the  spares  planning  and  acquisition,  as  well  as  the 
contractor  support  planning  and  acquisition. 
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d .  Problems :  The  task  normally  follows  the  established 

quality  control  procedures  of  a  corporation,  and  as  such  would 
differ  from  company  to  company.  Standardized  computerized 
techniques  other  than  configuration  control  and  data  traceability 
would  not  serve  this  task  too  well. 

e.  Implementation  Approach:  None  required. 


f. 


Implementation  Cost: 


None . 
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IDEF  A2 ,  CONCEPT  PAPER 
FOR 

CALS  INFLUENCE  ON  EQUIPMENT  DESIGN 


1.  FOCUS  OF  CALS  IMPLEMENTATION 

1.1  Overview .  The  principal  logistic  support  functions  which 

relate  to  those  equipment  design  attributes  that  influence  its 
support  (the  supportabi lity  attributes)  are: 

a.  Reliability  (1.2.2). 

b.  Maintainability  (1.2.3). 

c .  Safety  (1.2.4). 

d.  Human  Factors  (1.2.5). 

e.  Packaging,  Handling,  Storage  and  Transportability 

(1.2.6). 

f.  Life  Cycle  Cost  Drivers  (1.2.7). 

1.1.1  Readiness  and  Sustainability.  Each  of  these  place 
demands  on  the  support  resources  in  terms  of  their  complexity, 
their  quantity,  their  location  and  their  organizational 
utilization.  This  influences  the  support  costs  and  in  turn  the 
sustainability  of  the  equipment.  They  also  influence  the 
operational  readiness  of  the  equipment.  Although  the  latter  has 
rarely  been  linked  to  logistic  support,  shortcomings  in  readiness 
can  be  (theoretically)  compensated  for  with  an  abundance  of  the 
proper  replacement  Line  Replaceable  Units  (LRUs)  or,  if  need  be, 
entire  weapons  platforms. 

1.1.2  Inadequate  Analyses  and  Trades.  Life  Cycle  Cost  (LCC) 
analyses  and  trades  do  not  usually  postulate  the  alternative  of 
an  extra  weapon  system  to  make  up  for  the  lengthy,  difficult, 
unfixable  problems  resulting  in  a  reduction  in  readiness  of  a 
platform(s),  or  "Hanger  Queens"  (or  similar  cannibalization 
"reserves"  for  the  Army  and  Navy).  The  cost  relationships  are 
very  complex  and  have  not  yet  been  worked  out. 
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Because  of  this,  the  true  cause  and  effect  relationship 
between  specified  supportab i 1 ity  design  attributes  (many  of  which 
conflict  with  one  another)  have  not  yet  been  modeled  with  any 
degree  of  credibility.  Presently  it  is  believed  that  the  IDA 
RAMCAD  and  N3IA  MLCAD  surveys  will  indicate  that  many,  if  not 
all,  of  the  important  computerized  techniques  are  available  to 
analyze  the  supportab i 1  ity  attributes  of  a  design,  but  that  the 
interaction  between  them  and  the  "Big  Picture"  trades  are  not  yet 
possible . 

1 .2  Projected  Performance  of  the  Target  Computerized  Func¬ 
tions  .  The  evolution  of  utilization  of  computerized  techniques 
for  enhancing  the  supportability  attributes  of  a  design  has 
already  started  by  computeriz ing  many  of  the  "illities"  existing, 
normally  manually  prepared,  analytical  techniques.  Though 
presently  stand-alone  and  still  after-the-fact,  they  avail  the 
information  faster  for  more  timely  feedback  to  the  design 
process.  The  future  holds  that  these  techniques  will  become 
interactive  with  the  design  process,  as  described  in  the 
paragraphs  that  follow.  They  would  also  become  interactive  with 
each  other,  so  that  Reliability,  Maintainability,  etc.,  analyses 
results  could  become  truly  integrated  to  provide  for  the 
presently  unavailable  trades  between  attributes  as  follows: 

1.2.1  Realistic  Trades.  Models  will  exist  which  will  permit 
viable  trades  between  performance  compromises  (including  weight 
and  volume)  in  terms  of  mission  capability,  readiness,  etc., 
versus  reliability  and  maintainability  compromises,  versus  cost 
and  schedule  compromises,  in  order  to  optimize  these  critical 
attributes  of  a  design. 

1.2. 1.1  Automatic  Optimization.  These  models  would  also  be 


designed  to  perform  the  above  optimization  automatically  as  part 
of  the  design  process,  or  as  part  of  an  interaction  with 
system/equipment  partitioning  assessment  programs  (i.e., 


Performance  Simulation,  Repair  Level  Analyses  (RLA), 
Transportability,  Maintainability,  Testability),  to  optimize 
between  the  logistics  concept  and  performance  requirements. 

Once  the  trades  are  completed  and  accepted,  the  models  will 
also  be  able  to  apportion  and  allocate  failure  rates,  built-in¬ 
test  and  maintenance  turn-around  commensurate  with  the 
performance  criticality  of  each  of  the  modules,  since  these  will 
be  known  to  the  program  by  virture  of  the  trading  parameter. 

1.2. 1.2  Integrated  Diagnostics  and  Reliability  Centered 
Maintenance.  It  is  also  anticipated  that  in  less  than  ten  years 
hence,  the  automatic  modeling  and  development  of  trade-off 
factors  for  Integrated  Diagnostics  as  well  as  for  Reliability 
Centered  Maintenance  will  also  be  completed.  Equations  and 
relationships  for  Reliability  Centered  Maintenance  already  exist 
for  manual  evaluation.  These  need  only  be  coupled  with  the  yet 
to  be  developed  LCC  interrelation  of  readiness  and  sustainability 
to  provide  for  viable  optimizations  of  forced  removals  versus 
corrective  maintenance. 

Integrated  Diagnostics  is  still  in  its  infancy  as  concerns 
developing  factors  for  optimizing  between  various  maintenance 
techniques.  Industry  associations  and  RADC  are  working  the 
problem,  which  presently  appears  to  rely  heavily  on  LCC  modeling 
improvements  and  the  accurate  prediction  of  non-detectable 
failures  or  "cannot  duplicate"  failures.  A  present  trend  in 
improving  the  capabilities  of  testability  programs  hold  the 
promise  to  provide  more  accurate  predictions  of  the  Figures  of 
Merit  (FOMs)  for  use  in  the  trades. 

1.2. 1.3  Additional  Benefits.  In  addition  to  the  design  and 
data  benefits  described  above  and  in  paragraphs  that  follow,  it 
is  conceivable  that  many  standard  planning  documents 
(reliability,  maintainability,  ILS  plans,  etc.)  and  technical 
reports  (prediction  reports,  LCC  reports,  FMECA  reports,  etc.) 
can  be  replaced  by  direct  access  to  the  information  that  resides 
in  the  design  and  analyses  data  bases. 


1.2.2  Reliability.  Once  the  initial  spares  and  support 
resources  have  been  acquired,  virtually  all  recurring  support 
costs  (replenishment  spares,  touch  labor,  test  equipment 
utilization,  etc.)  are  directly,  and  in  most  cases  linearly, 
related  to  the  reliability  of  an  equipment  and  its  components. 
Reliability  requirements  are  usually  specified  with  regard  to 
what  has  been  attained  in  similar  equipment  or,  if  properly 
thought  out,  what  is  really  required  in  terms  of  the  function  or 
mission  of  the  equipment,  considering  the  maintenance 
capabilities  and  philosophies.  The  future  holds  that: 


Reliability 


1.2. 2.1 


Field  Data  Collection  Improvement. 


Actual  field  data 


will  be  collected,  sorted  and  analyzed  in  such  manner  that 
reliable,  meaningful  data  of  the  "Comparison  System"  (DoDD 
5000.39)  will  be  available  on-line  to  the  specification 
preparation  team  during  the  preparation  of  the  reliability 
requirements  for  the  new  system/equipment,  in  terms  of  its 
required  performance  functions,  allowable  degradations,  and 
critical  mission  requirements. 


1.2. 2. 2  Design  Rules  Preparation. 


Actual  field  data  will  be 


reduced  to  Lessons  Learned  for  the  Comparison  System,  or  general 
design  application,  and  stored  in  Design  Rules  Libraries  that  are 
accessed  automatically  and  transparently  in  the  same  computer  in 
which  the  design  is  evolving  (CAE/CAD),  much  like  a  spelling 
checker  is  accessed  in  word  processing,  except  automatically. 

The  library  would  be  continuously  updated  from  test  experience 
and  field  data. 

Subroutines  or  linked  programs  could  evaluate  the 
consequences  or  benefits  of  rejecting  or  accepting  the  rules  in 
terms  of  Equipment  Reliability,  Life  Cycle  Cost,  Mission  Success, 
and  similar  FOMs  in  short  order  for  use  by  the  design 
review/approval  team.  These  results  would  be  available  to  the 
designer  for  final  decision. 
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Likewise,  the  computer  could  perform  the  optimization 
automatically,  permitting  the  designer  to  also  test  various 
different  design  options. 

1.2. 2. 3  Standardization  of  Models.  The  many  reliability 
analyses  models  that  are  available  today  as  stand-alone  models 
would  be  standardized  and  approved  for  use  in  terms  of  how  they 
address  existing  (manual)  government-specified  and  industry- 
accepted  techniques.  These  approved  techniques  would  then 
interact  automatically  with  the  development  of  a  design,  via 
computerized  design  techniques,  in  such  manner  that  the 
information  is  available  to  the  designer  during  the  design 
process  to  enable  him,  rather  than  a  second  or  third  party,  to 
rectify  problems  and  optimize  the  reliability  of  the  item  being 
designed. 

1.2. 2. 4  Meaningful  Failure  Rates.  Reliability  analyses  would 
provide  meaningful  failure  information  (in  terms  of  original 
performance  requirements  as  developed  from  the  system/equipment 
level  trades)  at  the  input/output  boundary  of  the  item  analyzed 
in  order  to  develop  fault  detection/isolation  techniques  such  as 
Testability  Analyses,  Automatic  Test  Program  Generators,  and 
Sneak  Circuit  Analyses.  The  output  would  then  also  feed  the 
Integrated  Diagnostic  program,  once  developed. 

1.2. 2. 5  Stress  Considerations.  Existing  stand-alone  models 
that  consider  component/structural  member/machinery  stress 
(electrical  and/or  mechanical)  during  the  range  of  environmental 
and  performance  demands  will  be  linked  closer  to,  if  not 
interactively  with,  the  coraptuer-aided  design  engineering 
process.  This  will  provide  for  more  wide-spread  utilization  by 
the  designer  due  to  its  timeliness,  as  well  as  provide  an 
opportunity  for  streamlining  design  reviews. 

1.2. 2. 6  Streamlined,  Cost-Effective  Design  Reviews.  It  is 

envisioned  that  computerized  techniques  could  be  qualified  and 
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approved  much  like  accounting  techniques,  mathematical  techniques 
for  analyzing  performance,  or  predicting  behavior-based  physical 
and  mathematical  rules,  etc.  such  that  once  approved,  it  would 
suffice  to  establish  that  the  approved  design  analysis  technique 
was  employed  for  a  particular  design  and  it  resulted  in  the 
design's  approval. 

1.2. 2. 7  Interaction  with  Other  Techniques.  Outputs  of  the 
reliability  models  would  be  structured  so  as  to  interact  with 
dependent  programs,  such  as  maintainability,  and  directly  input 
to  the  LSAR  or  similar  support  resource  planning  analyses  and 
documentation. 

1.2. 2. 8  Elimination  of  Data  Items.  Classic  manually  produced 
data  items  will  be  eliminated,  and  all  reliability  related  data 
will  be  available  from  a  data  bank,  and/or  the  LSAR.  These  would 
be  accessed  (with  proper  security  in  place)  by  authorized 
personnel,  via  terminals,  for  their  application  in  CALS. 

1.2.3  Maintainability.  Maintainability  requires  two  distinct 
design  attributes.  Those  related  to  fault  detection  and 
isolation  (testability  attributes),  and  those  related  to  the 
correction  of  the  fault  ( repairabi 1 ity  attributes).  Both  require 
expensive  support  resources  in  the  form  of  tools,  test  equipment, 
manpower,  training,  and  technical  manuals  which  get  multiplied  by 
the  number  of  repair  sites  and  their  manpower  and  shop  loading. 
Spares  and  repair  material  requirements  are  normally  attributed 
to  the  reliability  of  an  item.  However,  such  a  plan  holds  only 
if  there  are  no  mistakes  made,  nor  damages  inflicted  during 
maintenance.  Classically,  spares  and  repair  material  projections 
do  not  consider  battle  damage. 

Experience,  particularly  with  electronic  equipment, 
indicates  large  problems  in  spares  depletion  due  to  errors  in 
diagnosis  at  all  levels  of  maintenance.  Errors  stem  from  Built- 
in-Test,  Automated  Test  Equipment,  poor  instructions,  inadequate 
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training,  technician  errors,  or  damage  inflicted  during 
maintenance.  These  all  relate  directly  to  the  techniques 
employed  for,  and  timeliness  of,  analyzing  the  testability  of  a 
design  and  preparing  test  programs  and  instructions  from  the 
results.  The  results  are  the  failure  to  meet  readiness  and 
supportability  objectives,  extremely  high,  usually  unanticipated 
support  and  support  related  data  costs,  and  severe  restrictions 
on  optimizing  the  maintenance  concept  for  the  equipment. 


Repairability  problems  exist  in  both  electronic,  and  to  a 
greater  degree,  raechanical/structural  designs.  These  relate 
largely  to  repair  accesses,  repair  difficulty,  poor  structural 
modularization  and  anthropometric  issues.  These  in  turn  relate 
directly  to  the  techniques  employed  for,  and  timeliness  of, 
analyzing  the  repairability  aspects  of  a  design  and  preparing 
modularization,  accessibility,  fastening,  connecting,  etc. 
optimizations 'trades;  designing  accordingly;  and  preparing 
appropriate  instructions  from  the  results. 


In  addition  to  the  previously  discussed  field  data  feedback 
and  viable  trade  models,  the  future  for  maintainability 
techniques  holds  that: 


1.2. 3.1  Greatly  Improved  and  Design  Interactive  Techniques. 

Presently  there  are  many  stand-alone  maintainability 
analytical  programs  available  which  will  perform  the  testability 
as  well  as  repairability  analyses  with  varying  degrees  of 
thoroughness,  and  complexity,  and  inputting  programs  such  as 
reliability,  FMECA,  LCC,  etc.  There  are  also  anthropometric 
models  being  developed. 


Just  as  for  reliability,  the  many  maintainability  analyses 
models  would  be  standardized  and  approved  for  use  in  terms  of  how 
they  address  existing  (manual)  government-specified  and  industry- 
accepted  techniques  (barring  the  introduction  of  better 
techniques,  i.e.,  for  testability).  These  approved  techniques 
would  then  interact  automatically  with  the  development  of  a 


1. 2.3.3  Streamlining  the  Design  Review.  It  is  envisioned  that 
just  as  for  reliability,  computerized  techniques  could  be 
qualified  and  approved  for  their  application  such  that,  once 
approved,  it  would  suffice  to  establish  that  the  approved  design 
analysis  technique  was  employed  for  a  particular  design  and  it 
resulted  in  the  design’s  approval. 

1.2. 3. 4  Program  Interaction.  Outputs  of  the  maintainability 
models  would  be  structured  so  as  to  interact  with  dependent 
programs  such  as  repair  level  analyses,  life  cycle  cost  analyses, 
transportability  analyses,  test  program  generation,  technical 
manual  repair  procedures,  maintenance  task  analyses,  manpower  and 
skill  analyses,  spares  and  repair  parts  identification  and  SMR 
coding,  and  support  equipment  analyses,  and  would  be  directly 
input  to  the  LSAR  or  similar  support  resource  planning  analyses 
and  documentation. 

1.2. 3. 5  Elimination  of  Data  Items.  Classic  manually  produced 
data  items  will  be  eliminated,  and  all  maintainability  related 
data  will  be  available  from  a  data  bank,  and/or  the  LSAR.  These 
would  be  accessed  (with  proper  security  in  place)  by  authorized 
personnel,  via  terminals,  for  their  application  in  CALS. 

1.2.4  Safety.  Although  safety  is  an  important  design 
consideration  for  operation  and  maintenance  of  an  equipment,  it 
is  also  an  important  consideration  in  product  liability,  and  has 
received  considerable  attention  from  that  aspect.  It  is  not 
considered  a  prime  candidate  for  improvement  in  Reliability, 
Maintainability  and  Supportability .  The  rules  checking  for 
safety  features  and  dangerous  items/conditions  will  eventually 
become  part  of  the  commercially  available  CAE  programs  by  virtue 
of  demands  made  by  the  private  sector,  which  has  a  greater 
exposure  to  product  liability  and  as  well  as  competition  for  user 
acceptance. 

1.2.5  Human  Factors.  Those  human  factors  considerations  that 
place  demands  on  skill  and  experience  for  maintenance  are  handled 


by  maintainability ,  wherein  the  analytical  techniques  discussed 
there  would  serve  to  optimize  the  demands  placed  on  the 
technician  as  well.  Human  factors  considerations  for  operation, 
manipulation,  and  maintenance  access  relate  to  the  anthropometric 
analyses  which  are  being  actively  developed  now.  Costs  relating 
to  the  technician,  his  training,  rotation,  sustenance,  and 
maintenance  aids  are  a  significant  part  of  an  item's  support 
cost.  The  future  holds  that: 

1.2. 5.1  Design  Interactive  Analyses.  Human  factors  analyses 
will  be  performed  in  three  areas.  First,  within  the  CAE  program 
itself  to  take  care  of  operational  anthropometric  considerations. 
Second,  within  the  maintainability  programs  to  take  care  of  at 
least  the  difficult  maintenance  actions.  Third,  in  separate 
anthropometric  modeling  for  access  and  repair/replacement. 

1.2. 5. 2  Use  of  Field  Data.  As  in  reliability  and 
maintainability,  actual  field  data  will  be  used  for  lessons 
learned  input  to  the  computerized  rules  checking.  However,  the 
actual  analyses  regarding  time,  skills  and  resources  will  be  part 
of  the  maintainability  analyses,  rather  than  another  stand-alone 
module.  Interpretations  and  tradeoffs  between  design  features  to 
accommodate  human  factors  will  remain  manual  tasks,  with  the 
computer  assisting  only  in  the  calculations. 

1.2. 5. 3  Battle  Damage  Assessment  Interaction.  Anthropometric 
maintenance  modeling  presents  the  opportunity  for  modeling  battle 
damage  situations,  if  it  were  interrelated  with  the  design 
program.  It  is  assumed  that  this  will  happen  by  virtue  of  its 
importance.  Support  Cost  advantages  however,  will  not  be 
predictable  until  the  operational  readiness  or  availability 
analytical  models  are  ready  to  equate  results  to  support  costs. 

It  is  suggested  that  this  must  happen  first  as  part  of  the  Life 
Cycle  Costs  modeling,  in  order  to  predict  the  seriousness  of  the 


lack  of  attention  to  battle  damage,  as  well  as  the  return  on 
investment  for  the  development  of  the  design,  and  design 
information  interrelation. 

Presently,  LSARs  do  not  collect  battle  damage  maintenance 
demand  data.  The  output  of  the  above  analyses  would  therefore 
require  changes  to  the  LSAR,  or  a  separate  data  base.  It  is 
assumed  that  the  latter  will  be  developed,  due  to  the  specialized 
nature  of  the  input  information  and  application  of  the  results  of 
subsequent  analytical  processes. 

1.2.6  Packaging,  Handling.  Storage  and  Transportation.  Except 
for  very  special  situations,  i.e.,  large  items,  or  dangerous 
handling,  this  is  not  a  support  cost  driver.  However,  it  has 
normally  not  been  considered  in  equipment  division.  The  future 
holds  that: 

It  will  continue  to  be  performed  manually. 

Maintainability  partitioning  and  repair  level  analyses 
programs  will  include  PHST  issues  which  will  then  be  input  to 
transportability  models  (manual). 

The  outputs  of  the  transportability  modeling  will  be 
formatted  so  as  to  directly  input  to  the  LSAR. 

1.2.7  Life  Cycle  Co3t  Drivers.  The  design  features  that 
affect  life  cycle  costs  to  a  significant  degree  are  as  follows, 
in  the  order  of  effect  on  present  modeling  considerations: 

Reliability 

Acquisition  costs  (spares) 

Standardization 

Support  Equipment  and  attendant  costs 

Manpower  costs 

Direct  repair  labor  costs 


The  above  issues  are  not  normally  related  to  independently 
variable  design  attributes.  To  the  contrary,  they  usually 
constitute  conflicting  design  considerations.  Therefore,  in 
order  to  achieve  the  lowest  LCC,  trades/optimizations  are 
required  between  these  design  related  issues.  This  requires  LCC 
modeling  that  has  been  sensitized  to  changes  in  one  design 
attribute  or  another  so  that  the  effect  on  changes  to  a  "same 
color  money"  cost  to  the  government  can  be  properly  assessed.  In 
addition,  to  be  of  any  value  in  design  influence,  the  trades  must 
be  performed  at  such  a  time  that  the  large  drivers,  rather  than 
the  inconsequential  ones  can  be  changed.  The  future  holds  that: 

Trades  between  design  attributes  will  include  LCC 
considerations  and  will  be  performed  at  the  same  time  that 
reliability  and  maintainability  analyses  are  performed,  so  as  to 
interact  with  the  design  process. 

Life  cycle  cost  models  will  include  proper  quantifiers  for 
availability/readiness,  as  well  as  true  government  overhead  costs 
for  material,  equipment  and  labor. 

Life  cycle  cost  will  become  a  serious  contractual  issue, 
second  only  to  acquisition  costs;  and  trades  will  become  the  tool 
of  the  program  manager  and  design  engineer,  as  opposed  to  the 
illities  engineer.  This  is  already  evident  in  highly  competitive 
commercial  items  such  as  automobiles  and  aircraft. 

1 . 3  Implementation  Considerations. 


1.3.1  Technical  Considerations.  The  major  technical  software 
design  problems  are  either  in  the  process  of  being  solved  (i.e., 
anthropometric  modeling),  or  have  already  been  resolved  in  stand¬ 
alone  programs  which  have  been  designed  primarily  to  digitize 


accepted  and  customarily  specified  analytical  techniques.  The 
implementation  considerations  remaining  then,  are: 


1.3. 1.1  Things  to  be  Developed: 

a.  Credible  and  usable  field  data  collection,  sorting  and 
feedback  for  inputs  to  reliability,  maintainability  and  other 
lessons  learned  computerized  libraries. 

b.  Development  of  models  (or  modifications)  to  address 
availability  and  readiness  in  terms  of  support  costs  for  trade 
models  ( i .e. ,  LCC) . 

c.  Development  of  proper  cost  factors  for  LCC  so  that  all 
items  contain  correct  overhead  burdening  for  equivalent  cost 
factors . 

d.  Development  of  models  which  will  permit  viable  trades 
between  performance  compromises  and  reliability,  maintainability 
and  supportability . 

e.  Modeling  of  Integrated  Diagnostics  as  a  trade-off  tool 
for  fault  detection/isolation  techniques  and  requirements  at 
various  maintenance  levels. 

f.  Techniques  for  interaction  with  CAE/CAD. 

g.  Techniques  for  coramunications/interaction  between 
analytical  techniques,  the  LSAR,  and  the  data  users. 

h.  Techniques  for  computerized  development  of  detailed 
specifications  and  work  statements  that  properly  address 
reliability,  maintainability  and  supportability  requirements, 
commensurate  with  the  use  and  maintenance  scenario  of  the  weapon. 

i.  The  modeling  of  integrated  diagnostics  and  reliability 
centered  maintenance. 

j.  Battle  damage  assessment  and  repair  action  analyses  and 
instructions. 


1.3.2  Contractual  Issues.  The  following  are  non-technical 
issues  that  require  consideration  in  specifications,  statements 
of  work  and  contractual  terms  and  conditions: 

a.  What  is  required  to  have  a  developer  improve 
reliability,  maintainability  and/or  supportabi lity  of  an 
equipment  that  already  meets  the  contractual  requirements.  What 
contractual  issues  are  involved. 

b.  What  would  incentivize  or  otherwise  require  a  developer 
to  utilize  these  techniques.  What  contractual  issues  are 
involved  in  this  and  in  data  preparat ion/del i very/user- 
utilization. 

c.  What  would  be  the  contractual  considerations  to  require 
a  developer  to  properly  address  built-in-test  and  testability. 

d.  What  are  the  end  bounds  for  the  trading  of  performance, 
weight  and  volume  requirements  against  reliability, 
maintainability  and  supportability  design  features. 

e.  What  are  the  issues  of  warranties  and  product 
performance/safety  liabilities. 

f.  Where  lies  the  responsibility  for  battle  damage 
workaround . 

g.  What  are  the  security/proprietary  issues  of 
computerized  interfacing  and  design  review. 

1.3-3  Integration  Issues.  Integration  of  the  reliability  and 
maintainability  computerized  models  with  CAE/CAD  programs  appears 
difficult  in  light  of  the  progress  made  with  independent, 
commercially  available  programs  for  these  interdependent 
techniques.  The  possibility  of  interfacing  in  some  rapid  manner, 
rather  than  real-time,  should  be  considered.  Certainly  that 
would  be  quicker  than  any  presently  available  technique  where  a 
different  (from  the  designer)  discipline  performs  the  analyses. 
Even  though  the  turn-around  time  has  been  reduced  to  acceptable 
levels  by  computerized  techniques,  it  is  still: 
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a.  Subject  to  the  classic  "not  invented  here"  rejections 
by  the  designer. 

b.  In  series  with  the  completion  of  a  design,  even  if  the 
design  is  in  digitized,  not-yet-drawn,  format.  Consequently,  it 
would  require  a  costlier  change  than  if  interactively  prepared  by 
the  designer  himself. 

c.  The  present  direction  of  computerized  design  is  towards 
a  paperless  information  transfer  from  design  to  machining.  The 
information  that  is  being  transferred  in  this  manner  is  not 
usable  for  reliability,  maintainability,  supportability , 
testability,  technical  manuals  or  LSAR  inputs.  Intermediate 
products  compatible  with  the  input  requirements  of  these  will 
have  to  be  provided.  To  be  considered: 

(1)  Pictorial  information  rendered  for  inclusion  in 
technical  manuals. 

(2)  Parts  listings,  numbering  and  used-on  information 
from  the  bill  of  materials  for  use  in  parts  lists  and 
provisioning  documentation. 

(3)  Numbering  systems  compatible  with  LSAR  numbering 

systems . 

(4)  Information  from  the  field  of  drawings  (dimensions, 
values,  nomenclatures,  pin  assignments,  etc.)  for  use  in 
technical  manuals  and  for  testability  programs,  test  program 
generators  and  support  equipment  requirements. 

1 .4  Likely  Payoffs  and  Benefits. 

1.4.1  Preliminary  Assessment  of  Stand-Alone  Techniques.  The 

potentials  available  from  employing  stand-alone  computerized 
analytical  techniques  for  reliability,  maintainability  and 
supportability  analyses  are  already  known.  The  techniques  have 
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resulted  in  quicker,  more  thorough  and  accurate  analyses,  and 
have  as  a  minimum  provided  for: 

a.  Correction  of  major  design  problems. 

b.  Improvement  in  testability. 

c.  Preparation  of  better  test  programs. 

d.  Paved  the  way  for  integrated  diagnostic  trades/modeling. 

e.  Improvement  in  reliability  stress  modeling,  thereby 
providing  designs  more  capable  of  meeting  specified  requirements. 

f.  Improved  acceptance  of  results  by  illities  engineers  and 
designers. 

g.  Government  sponsored  demonstrations  of  feasibility  and 
advantages  of  the  techniques  to  provide  design  improvements. 

h.  IR&D  investment  by  many  large  firms  in  utilization  and 
development  of  analytical  techniques  for  their  particular 
application. 


1.4.2  Preliminary  Assessment  of  Interactive  Techniques. 

Presently  the  techniques  for  utilizing  the  information 
available  from  the  computerized  analyses  have  not  changed  from 
that  of  manual  techniques,  in  that  data  are  still  transferred 
manually  from  one  user  (person  or  program)  to  another.  There  is 
still  much  duplication  in  analyses  and  data  products  preparation, 
and  design  engineering  acceptance,  though  improved,  falls  short 
of  a  more  desirable  design  engineer’s  utilization  of  the 
techniques . 

By  combining  or  interacting  some  of  the  more  critical 
reliability,  maintainability  and  supportabi 1 i ty  analyses  with  the 
CAE/CAD  employed  by  the  designer,  the  designer  himself  would  be 
directly  interacting  with  the  assessment  and  development  of 
optimized  R,M&S  design  attributes.  Communicating  between  the 
programs  would  be  automatic  and  require  no  transcription.  Some 
of  the  major  benefits  would  be: 


a. 


Greater  innovation  in  obtaining  reliable  and 
supportable  equipment  beyond  the  specified  requirements,  thus 
improving  readiness  and  sustainability.  It  would  also  become 
possible  to  specify  and  obtain  more  stringent  R,M&S  requirements 

b.  Reduced  development  costs. 

c.  Reduced  manufacturing  costs  by  eliminating  corrective 
redesign. 

d.  Reduced  manufacturing  costs  by  virtue  of  providing 
testability  and  ease  of  maintenance  design  attributes  which  also 
result  in  quicker  assembly  line  testing  and  assembly  of  an  item. 

e.  Elimination  of  manual  data  preparation  practices,  thus 
reducing  data  costs  by  orders  of  magnitude. 

f.  Provision  of  accurate  analytical  data  traceable  to  the 
design  features  and  design  configurations. 

g.  Elimination  of  duplicative  efforts  by  providing  direct 
inputs  to  the  LSAR,  spares  documentation  and  technical  manual 
preparation. 

h.  Potential  for  eliminating  all  paper  data  by 
transferring  only  the  elemental  information  from  which  data 
products  are  normally  prepared. 

i.  Potential  for  remote  design  reviews. 

j.  Potential  for  use  by  subtiers  and  small  firms  who 
develop  less  than  major  systems  and  subassemblies  whose 
reliability,  maintainability  and  supportabi 1 ity  nonetheless  have 
significant  impact  on  the  weapon’s  readiness  and  sustainability. 

1.5  Changes  Needed  and  Problems. 

1.5.1  Changes  Needed.  Besides  the  implementation 
considerations  of  paragraph  1.3,  it  is  thought  that  the  most 
important  and  cost  effective  resulting  recommendation  for  change 


to  the  present  way  of  doing  business  is  the  structuring  of  an  RFP 
and  Performance  Specification  utilizing  (as  yet  to  be  developed) 
computerized  techniques  to  guard  against  omissions,  and  to  assist 
in  and  provide  assurance  of  the  inclusion  of  specifically 
tailored  R,M&S  related  design  requirements. 

1.5.2  Anticipated  Problems.  Some  of  the  problems  beyond  those 
enumerated  in  paragraphs  1.3  and  3.  are: 

a.  The  utilization  of  the  computerized  techniques  by  prime 
contractors,  i.e.,  weapon  platform  manufacturers  without  their 
subtiers'  utilization  of  comparable  or  even  compatible 
techniques.  This  would  be  especially  troublesome  if  the 
subtiers’  equipment  is  the  reliability,  maintainability  or  life 
cycle  cost  driver. 

b.  Prime  contractors'  failure  to  pass  incentives  and  other 
contractual  benefits  to  the  subtiers  who  are  utilizing/developing 
computerized  techniques. 

c.  Reluctance  by  data  users  to  adapt  to  modern  data 
transfer  and  information  presentation. 

d.  Reluctance  by  design  review  teams  to  accept  an 
analytical  program's  design  approval.  This  would  have  the 
potential  of  duplicating  computerized  techniques  manually  to 
establish  confidence. 

e.  The  eventual  evolvement  into  a  no-hardcopy-backup 
situation. 

f.  How  to  check/validate  a  computerized  technique  as  to 
accuracy,  completeness  and  freedom  of  glitches. 

2.  IDENTIFICATION  OF  CANDIDATE  FUNCTIONS 

2.1  Candidates  for  Automation.  All  of  the  presently  specified 
reliability,  maintainability,  repair  level  and  life  cycle  cost 
models  should  be  automated.  Most  of  this  has  already  taken  place 
with  computerized  models  commercially  available.  Some  are 


available  as  GFE .  It  is  suggested  that  all  be  made  available  as 
GFE  to  companies  that  do  not  have  these  techniques  in  place.  In 
addition,  the  following  should  be  developed: 


a.  Analyses  for  readiness  and  sustainability. 

b.  Automatic  techniques  for  specification  preparation. 

c.  Spares  cost  projections  for  input  to  LCC  and  LSAR. 

2.2  Candidates  for  Standardization.  All  of  the  presently 
specified  reliability,  maintainability,  optimum  repair  level  and 
life  cycle  cost  models  that  are  automated  should  be  standardized 
against  the  attendant  specification  in  the  same  manner  that 
manual  techniques  are.  Data  dictionaries  for  input  and  output 
data  structure  and  labels  must  be  standardized  to  enable 
communication  between  programs  and  users.  The  standardization 
must  consider  the  MIL-STD-1 388-2A  Data  Dictionary. 

2.3  Candidates  for  Integration. 

2.3.1  Integration  with  CAE/CAD.  The  following  generic 
analytical  techniques  should  be  integrated  with  CAE/CAD: 

a.  Reliability: 

Parts  failure  rate  catalogue 

Lessons  learned  failure  rate/parts  application  feedback 
Preferred  parts  lists 
Parts/material  application 
Parts  tolerance  analyses 

Stress  analyses,  electrical,  thermal,  vibration,  etc. 

Predictions 

FMECA 

Allocations  to  lower  assemblies 


Sneak  circuit  analyses 
ATE  compatibility  analyses 
Testability  analyses  (includes  BIT) 

Elemental  maintenance  actions  catalogue 
Lessons  learned  maintenance  task  difficulties 
Maintenance  access 
Predictions 

c.  Other 

Life  cycle  cost  analyses 
Readiness/availability  analyses 
anthropometric  analyses 

2.3.2  Integration  with  Each  Other.  The  following  generic 
analytical  techniques  should  be  integrated  with  each  other: 

a.  All  the  techniques  of  2.3.1. 

b.  Reliability 

Mission  reliability  predictions 
Construction  of  reliability  diagrams 
Construction  of  functional  block  diagrams 
Reliability  centered  maintenance  analyses 
Reliability  risk  analyses 

c.  Maintainability 

Integrated  diagnostics  analyses 
Level  of  repair  analyses 
Maintenance  task  and  skill  analyses 

d.  Other 

PHST  analyses 

Spares  cost  projections 
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ANTICIPATED  RECOMMENDATIONS 


3.1  Funding  Issues.  It  is  anticipated  that  recommendations 
will  involve  matching  funds  for  IR&D  and/or  development  funds  if 
requirements  for  computerized  techniques  are  specified  in  a 
contract . 

3.2  Incentive  Issues.  Incentives  will  have  to  be  addressed  if 
the  desired  result  for  using  computerized  techniques  is  to 
provide  better  than  specified  equipment,  reducing  data  costs  and 
support  resource  costs. 

3.3  Contracting  Issues.  The  use  of  computerized  techniques 
would  reduce  the  manpower  required  to  perform  analyses,  prepare 
data,  etc.,  thus  reducing  the  overhead  base  of  a  company’s  fee 
structure.  New  regulations  and  contracting  techniques  will  have 
to  be  developed  to  compensate  for  this. 

3.4  Competitive  Issues.  The  specifying  of  reliability, 
maintainability,  supportability,  analytical  techniques,  etc.  in 
an  RFP  will  provide  the  tremendous  advantage  of  competition 
leverage  such  that  competing  contractors  will  of  themselves 
implement  the  computerized  techniques  in  order  to  be  responsive 
as  well  as  competitive.  THIS  IS  THE  SINGLE  MOST  COST  EFFECTIVE 
TECHNIQUE  FOR  THE  GOVERNMENT  TO  CAUSE  INDUSTRY  TO  UTILIZE  CALS! 

3.5  Specification  and  Standards  Issues.  Specification  and 
standards  issues  must  be  addressed  prior  to  any  other  issue  due 
to  the  proliferation  of  independent,  stand-alone  models,  as  well 
as  the  need  to  have  many  of  these  interface/interact  with  each 
other,  the  users  and  reviewers. 

It  is  expected  that  an  interim  measure  will  be  recommended 
in  which  it  will  be  suggested  that  existing  standards  for  manual 
techniques  be  changed  to  permit  computerized  techniques.  This 
would  be  the  simplest  way  to  get  things  started. 


3.6  Technological  Changes.  It  is  expected  that  technological 
changes  for  information  transfer  between  programs  will  be  required. 

3-7  System  Characteristics.  The  issues  of  security,  concern 
of  data  loss  and  unauthorized  manipulation,  rights  in  technical 
data  and  proprietary  techniques,  untimely  review  and  similar  concerns 
range  uppermost  in  industry  and  will  have  to  be  addressed  in 
contractual  and  well  as  policy  issues. 

3.8  Policy  Issues.  Present  DoD  Policy,  i.e.,  5000.39,  already 
provides  that  the  R,M&S  issues  of  a  system  be  addressed  during 
design,  without  specifying  the  technique.  Therefore,  the 
computerized  techniques  are  responsive  to  that  policy  without 
change.  However,  it  is  expected  that  recommendations  regarding 
incentives,  contracting  and  the  issues  of  security  and 
proprietary  rights  will  require  new  or  changed  policies. 

4.  JUSTIFICATION  FOR  THE  CHOICE  OF  CANDIDATES 

4.1  High  Payoff.  As  previously  discussed,  the  reliability  and 
maintainabi 1  ity  candidates  provide  the  opportunity  for  high 
payoff  in  terms  of  readiness  and  sustainability,  as  well  as  lower 
costs  for  development,  manufacture  and  data  preparation. 

4.2  Feasibility.  The  fact  that  most  of  these  computerized 
techniques  are  already  available  and  some  are  being  demonstrated 
for  value  in  design  improvement  attests  to  their  feasibility. 

Many  programs  are  already  interactive,  indicating  the  feasibility 
of  communications.  Progress  in  interface  specifications  for  CAD 
to  CAM  and  pictorial  to  text  processing  indicate  that  inter¬ 
facing/interacting  with  CAE/CAD  techniques  is  also  feasible  for 
the  reliability,  maintainability,  PHST  and  life  cycle  cost  driver 
target  functions. 


4.3  High  Leverage.  The  reliability,  maintainability  and  life 
cycle  cost  driver  analyses  are  the  principal  functions  which  will 
identify  the  design  attributes  required  for  optimizing  readiness 
and  sustainability  of  the  equipment.  They  are  also  the  principal 
generators  of  the  design  and  support  information  necessary  for 
the  development  support  plans,  technical  manuals,  training 
material  and  plans,  spares  recommendations  and  coding,  and  all 
other  support  resources. 
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A22  Perform  Allocations 

There  are  six  activities  which  describe  the  allocations  process. 
Starting  the  diagnostic  procedure  at  all  maintenance  levels  is  the  first  of 
these  activities.  This  is  a  rough  cut  procedure  for  fault  detection  and 
fault  isolation.  For  example,  prior  to  performing  any  other  trades,  modem 
electronic  design  is  structured  to  result  in  functional  packaging  in  order 
to  facilitate  fault  detection  and  fault  isolation.  Fault  detection  and 
isolation  times  are  then  proportionately  divided  among  these  modules. 

Equipment  partitioning  is  the  second  activity  which  provides  the 
division  of  equipment  or  assembly  into  its  next  lower  level  of  assembly.  It 
utilizes  the  test  node  information  from  the  diagnostic  procedure,  as  well  as 
the  RLA  to  perform  this  task.  The  model(s)  would  automatically  optimize 
between  division  for  the  sake  of  testability  (functional),  packaging  and 
transportability,  cost  (standardization  and  multi-application),  performance, 
etc.  as  part  of  the  design  process. 

The  third  activity  is  the  establishment  of  reliability  allocation. 

This  provides  the  allocated  MTBF  to  the  module  as  it  has  been  partitioned, 
as  well  as  narrows  the  selection  of  preferred  parts  to  be  used  in  the  design 
of  the  module.  The  search  of  the  parts  library  as  it  is  done  today  could 
possibly  be  improved  in  that  the  process  of  designing  a  performance  of  an 
item  could  very  well  narrow  down  the  range  of  parts  that  could  provide  that 
performance,  and  with  that  prescreening  could  save  a  considerable  amount  of 
time.  Also  if  done  properly  the  prescreening  could  result  in  the  parts 
listing  to  be  contained  on  the  drawing's  bill  of  material  automatically,  as 
well  as  be  provided  in  text  processor  format  for  use  in  editing  into  parts 
lists  and  LSAR  inputs. 

Activity  four  is  the  conducting  of  trades.  This  activity  provides  for 
optimizing  Reliability,  Maintainability,  Supportability,  Design  and  Main¬ 
tenance  Concepts  during  the  allocation  process.  Future  trades  however, 
would  also  model  readiness  and  sustainability,  as  well  as  the  effects  on 
transportability.  The  latter  would  be  modeled  in  such  a  way  as  to  interact 
with  the  equipment  partitioning  or  modularization  of  the  equipment  being 
designed,  which  in  turn  would  interact  with  the  maintainability  allocations 
and  reliability  allocations. 

Maintaining  allocations  is  the  fifth  activity.  This  provides  the 
allocated  MTTR  to  the  module  as  it  has  been  partitioned.  It  also  serves  to 
separate  task  times  between  testing  tasks,  remove  and  replace  tasks,  and 
repair  tasks.  The  development  of  the  partitioning  program(s)  would 
automatically  provide  the  MTTR  apportionment,  and  no  further,  special 
development  for  this  apportionment  will  be  required. 

The  last  activity  is  providing  firstcut  Failure  Mode  Effects  and 
Criticality  Analysis  (FMECA).  This  tests  the  equipment  partitioning  from  a 
standpoint  of  assessing  the  effect  and  propagation  of  functional  failures. 

It  identifies  problems  in  performance  degradation,  fault  detection,  fault 
isolation,  as  well  as  critical  failures  and  parts.  Its  function  in  the 
allocation  process  is  primarily  of  optimizing  the  equipment  partitioning, 
identifying  potential  design  problems,  and  attempting  to  prevent  the  use  of 
critical  components  and  circuits.  There  are  digital  techniques  available 
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A22  Perform  Allocations  (Con't) 

but  these  are  usually  used  when  design  information  is  available  during  the 
analytical  process. 

G1  ossary 

Specified  Technique  -  Analytical  methods  as  specified  by  contract. 

Testing  -  To  check  performance  by  test. 

BIT  FOMS  -  Built-In  Test  Figure  of  Merit. 

Detection/ Isolation  FOM  -  ie  detection  ratio,  fault  isolation  ratio. 

Skill  -  Skill  requirements  for  the  maintenance  task. 

Maintenance  Philosophy  -  Description  of  how  maintenance  is  to  be  performed. 

Performance  -  The  operating  requirements  of  the  system. 

Manual  -  Performed  manually  as  opposed  to  automatically  or  computerized. 

Test  Times  -  Time  to  perform  an  elemental  test. 

Ambiguities  -  Identification  of  more  than  one  probably  cause  for  a 
malfunction. 

Test  Nodes  -  Circuit  junctives  at  which  testing  is  to  be  performed. 

Module  Perb.  4  Size  -  Module  performance  and  physical  size. 

RLA  -  Repair  Level  Analysis. 

Maintenance  Phil.,  Skill,  Performance,  Target  Support,  Cost,  Overall 
MMH/OH  -  Maintenance/Manhour  Operating  Hour. 

Skills,  Manpower,  MTTR  -  Mean  Time  to  Repair. 

Preferred  Parts  -  A  listing  of  parts  of  first  choice  for  design. 

MTBF  -  Mean  time  between  failures. 

Parts  Library,  Performance,  Overall  MMH/OH  -  Maintenance  manhour  per 
operating  hour. 

Size,  Weight  PHST  -  Packaging,  Handling,  Storage  and  Transportation. 

Defined  Degrees  of  Freedom  -  Allowable  deviations  from  the  specified  norm. 

Test  Points  -  Circuit  locations  at  which  to  perform  measuremenus. 

Critical  Parts  -  Parts  whose  failure  cause  serious  or  dangerous  system 
problem s. 

Ambiguities,  Bit  Problems  -  Built-In  Test. 


Table  2-9.  IT^F  A22,  CONTRACTOR  (sheet  3  of  3) 

A 22  Glossary  (Con't) 

LCC  -  Life  Cycle  Cost. 

Perform,  Risk  -  Risk  in  attaining  required  performance. 

Transportability  -  Requirements  for  transporting  an  item  of  equipment. 

Readiness  Sustainability  -  Figures  of  merit  to  measure  system  operational 
readiness  and  to  keep  it  operationally  available. 
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A24  Perform  Analyses 

The  performance  of  analyses  consists  of  six  activities.  Reliability 
stress  analysis  Is  the  first  of  these  activities.  This  ana1y»s  a  proposed 
design  to  determine  the  effect  of  stress  on  the  performance  and  reliability 
of  that  design.  The  analysis  requires  detailed  design  Information. 
Electrical  design  and  component  Information  Is  required  to  perform 
electrical  stress  analyses.  The  thermal  stress  analyses  apply  to  parts 
location  Information.  Ambient/cooling  air  Information  Is  required  for 
thermal  stress  analyses. 

An  envl ronmental  profile,  together  with  mechanical  layout  and 
packaging  Information  Is  required  to  perform  environmental  stress  analyses, 
which  could  range  from  temperature  and  mechanical  shock  to  vibration  and 
other  mechanical  stresses  on  the  components,  as  well  as  the  chassis  or 
circuit  board  upon  which  these  are  mounted.  The  assumption  Is  that  all  this 
information  will  be  available  to  the  analytical  techniques  of  the  future, 
such  that  these  analyses  could  be  performed  interactively  with  a  CAE/CAD 
program. 

Testability  analysis  is  the  second  activity.  This  activity  analyzes  a 
circuit  to  determine  whether  or  not  it  Is  testable  for  all  its  performance 
attributes  with  the  test  facilities  that  are  resident  in  the  circuit.  There 
are  two  major  approaches  to  this.  One  is  a  by-  product  of  a  circuit 
analyses  for  purposes  of  determining  its  capability  to  perform  its  intended 
function,  which  is  sometime  labelled  a  sneak  circuit  analyses,  or  circuit 
performance  analyses.  The  other  is  a  purely  statistical  technique.  The 
statistical  technique  will  only  provide  a  figure  of  merit,  whereas  the 
detailed  analyses  will  actually  provide  information  for  test  point 
placement,  as  well  as  the  development  of  fault  isolation  procedures. 

The  third  activity  is  providing  FMECA.  This  provides  the  failure 
modes,  effects  and  criticality  analyses  of  the  item  being  designed,  as  well 
as  of  its  next  higher  level  of  assembly  from  inputs  provided  it 
automatically  from  the  design  process,  and  the  results  of  the  reliability 
and  testability  analyses. 

Transportability  and  repair  level  analyses  comprise  the  forth 
activity,  this  seeks  to  ascertain  the  most  economical  maintenance  and 
maintenance  level  of  the  item  in  question.  It  uses  life  cycle  cost  modeling 
with  which  to  test  the  cost  effectiveness  of  each  maintenance  concept 
evaluated,  including  that  of  discard.  The  target  system  would  provide  for 
automatic  inputting  to  the  model,  as  well  as  its  interaction  with  the  other 
models. 


The  fifth  activity  is  maintainability  analysis.  This  prepares  the 
Maintainability  Analyses  of  a  design.  The  final,  detailed  Maintainability 
Analyses  require  input  from  the  Reliability  Analyses,  the  Testability 
Analyses,  the  Test  Procedures,  the  FMECA  and  design  information  in  terms  of 
the  assembly,  cabling,  assembly  process,  components  and  component 
placements,  fasteners,  nomenclatures,  and  reference  designators.  Feedback 
from  the  Repair  Level  Analysis,  if  performed,  is  also  required. 


Table  2-10.  ITF.F  A?4,  CONTRACTOR  (sheet  ?  of  2) 


A24  Perform  Analyses  (Con’t) 

The  last  activity  Is  the  performance  of  human  factors  and  safety 
analyses.  This  analysis  Mill  automatically  analyze  the  design  from  the 
standpoint  of  Mork  access  and  other  anthropometric  considerations.  It  Mill, 
together  m1 th  the  Maintainability  Analyses,  determine  the  task  and  skill 
requirements,  as  Mell  as  training  requirements  of  the  malntalner  and 
operator.  Since  the  Safety  Analyses  are  closely  linked  to  the  Human  Factors 
Analyses  and  ascertain  dangerous  voltages,  poMer  levels,  hazardous  tasks, 
sharp  edges,  toxic  material,  etc.  they  Mould  become  an  Interactive  part  of 
the  human  factors  analyses. 
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DEMONSTRATE  AND  APPROVE  DESIGN/MODIFICATION,  CONTRACTOR 
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PROVIDE  LOGISTICS' RESOURCES,  CONTRACTOR 


CONTEXT  i 
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CALS  FUNCTIONAL  DESCRIPTIONS 
CONTRACTOR  FUNCTIONS: 

8.  IDEF  A31,  Contractor  Field  Support 


PROVIDE  CONTRACTOR  FIELD  SUPPORT 


IDEF  A31  DESCRIPTION 
CONTRACTOR  FIELD  SUPPORT 


CURRENT  STATUS 

Primarily  hard  copy 

Inputs 

Controls 

Resource  management  primarily  manual 

TARGET  SYSTEM  CHARACTERISTICS 

Automated  (soft  copy) 

Inputs 

Controls 

Automated  resource  management 


BENEFITS 

Sites  activated  on  schedule  with  complete  support 
capability  matching  supported  system  configurations 

Rapid  response  to  keep  support  configurations  current 
with  system  changes 


PROBLEMS 

Compatibility  of  contractor  and  Government  data  systems 

Availability  and  compatibility  of  contractor  data 

Proliferation  of  high  capacity  PCs  promotes  creation 
and  utilization  of  individualized  unique  systems 
exacerbating  the  centralized  control  and  coordination 
problem 


IMPLEMENTATION  APPROACH 

Standardize  specifications  imposed  by  Services  on 
contractors  for  automation  of  deliverable  technical 
data 


Services  establish  own  automation  capabilities  to 
utilize  and  mesh  with  contractors  automation  systems 

Establish  DoD  oversight  of  Service  activities  in  this 
area  and  provide  specific  DoD  direction 

Provide  adequate  funding 


IMPLEMENTATION  COST 

The  approach  is  too  MACRO  at  this  point  for  any  kind  of 
useful  cost  estimate 
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A32  Provide  Training 

The  basic  data  that  will  be  used  to  develop  the  training  programs  will 
come  from  the  eng  aer's  design  data  base.  However,  training  experts  will 
ha/e  more  and  earlier  input  into  the  design  process,  requiring  equipment  to 
be  designed  with  both  embedded  and  external  training  as  part  of  the  design 
criteria. 

LSA  data,  an  offshoot  of  the  design  data  base,  will  also  be 
computer-generated.  This  addition  to  the  data  base  will  then  be  used  for 
the  development  of  the  maintenance  task  analyses  which,  in  turn,  leads  to 
the  training  courseware.  It  forms  the  heart  of  the  planning  of  the  training 
programs  and  will  be  part  of  the  total  data  base. 

Manuals,  documentation,  and  other  forms  of  job  aids  will  also  be 
nonpaper-based  in  the  future.  Job  aids  will  be  stored  digitally  in  the 
system  or  in  specially  designed  ATE,  and  can  be  outputted  as  video,  audio, 
text  and/or  a  combination  thereof.  Such  job  aids  will  be  available  either 
by  user  demand  or  system  initiation. 

Equipment  repair  will  be  taught  by  modeling  the  steps  and  actions 
which  have  to  be  taken  by  the  repairer.  In  the  electronic  manuals  of  the 
future,  this  may  take  place  by  having  the  system  "dump"  video  and 
instructional  logic  into  the  repairman's  portable  integrated  videocomputer. 
The  interface  for  such  a  device  must  include  options  which  allow  for 
hands-free  operation  of  the  training  device  (e.g.,  speech  input/output)  by 
the  repairman. 

Systems  operations  training  will,  to  a  great  extent,  be  resident  on 
the  system.  Initial  training  will  be  the  exception  to  this,  but  even 
initial  training  will  be  affected  (i.e.,  reduced  training  requirements)  by 
embedding  operations  training  in  the  system. 

New  forms  of  training  data  will  be  developed  to  use  the  data  base 
generated  in  design.  However,  they  will  be  formatted  to  be  suitable  for 
interactive  instructional  purposes.  A  new  skill,  combining  the  technologies 
of  engineering,  training,  and  authoring,  will  be  developed  to  put  a  suitable 
instructional  program  together.  Authoring  software  will  also  be  necessary 
to  convert  the  training  methodology  into  electronic  form  suitable  for 
interaction. 


Figure  2-18.  IDEF  A32n,  PROVIDE  TRAINING,  CONTRACTOR 


Table  2-12.  IDEP  A12n,  SUMMARY  (sheet  1  of  2) 


A32n  Provide  Training 

Three  activities  are  used  to  describe  the  framework  for  training.  The 
first  activity  is  the  definition  and  acquisition  of  training  equipment. 
Training  equipment  is  presently  defined  by  individuals  knowledgeable  in  the 
methodologies  of  training  for  the  system  in  question,  and  in  the  results 
required.  They  would  develop  a  plan,  determining  hardware,  software,  and 
procedures;  issue  purchase  requisitions,  specification  and  design  require¬ 
ments;  and  make  the  appropriate  arrangements  to  acquire  all  training 
materials. 

The  next  activity  is  the  development  of  courses.  A  System's  training 
course  is  now  planned  and  written  after  the  design  is  completed,  and  usually 
after  the  hardware  is  built.  Actual  hardware  is  used  to  help  design  the 
course  by  running  it  through  its  paces  and  introducing  faults  and  simulated 
situations.  Courses  are  now  developed  for  either  computer-based  training, 
human  interaction,  or  simulation  techniques  using  actual  hardware. 

The  last  activity  is  the  actual  conducting  of  training.  Computer- 
based  instruction,  equipment  simulation,  and  classroom  and  field  training  on 
actual  equipment  are  all  presently  used. 

Innovations  which  will  affect  training  will  occur  in  computer,  video 
and  training  technologies.  Computer- related  advancements  which  will  impact 
training  include:  improved  user  interfaces,  cheap  memory,  multi-tasking 
machines,  powerful  handhelds,  and  reasonably  costed  3-D  color  graphics 
systems . 

Training  technologies  will  advance  to  take  advantage  of  delivery  media 
improvements.  Artificial  intelligence  (AI)  concepts  will  be  directly  or 
indirectly  applied  to  training.  That  is,  where  feasible,  we  will  use  expert 
training  systems  to  provide  instruction  and  assistance  to  operators  and 
maintenance  personnel. 

G1  ossary 

Cost,  Schedule,  Requirements  -  Cost  and  Schedule  restrictions  are  provided 
by  the  contract  Statement  of  Work.  On-the-job  (OJT)  training  for 
persons  not  familiar  with  the  equipment  could  allow  performance  of  a 
task  by  using  built-in  computer  aids.  Defined  by  the  contact 
Statement  of  Work  as  to  the  type  of  training  required  on  the  program. 
It  could  be  formal,  classroom  training,  on-the-job  (OJT)  training,  or 
other  types. 

Technical  Specification  -  That  document  provided  as  part  of  the  contract 

which  defines  the  operational,  design  and  performance  requirements  of 
the  system. 

Maintenance  Plan  -  Equipment  Specification  and/or  Maintenance  Scenario 
Analyses  at  a  higher  level. 

Instructional  System  Design  Reqts  -  Maintenance  training,  operator  training, 
and  general  basic  training  as  defined  by  design  requirements. 
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Table  2-12.  IEEP  A32n,  SUMMARY  (sheet  2  of  2) 


A32n  Glossary  (Con 1 1 ) 

Design  Description  -  Results  of  the  design  program;  Including  drawings, 
analysis,  schematics,  test  results. 

Order  -  The  process  and  data  used  to  order  material  and  services. 

Training  Material  -  Data  used  to  conduct  the  training,  other  than  the 
courseware  (description  of  trainers,  mock-up,  etc). 

Training  Aids  Requirements  -  The  use  of  the  training  devices  and  how  to 
Integrate  them  into  the  overall  training  program. 

LSA  data  -  Logistics  Support  Analysis  data. 

Technical  Manuals  -  As  provided  by  Reliability  and  Maintainability  design 
analysis. 

Testing  Material  -  The  material  used  to  evaluate  the  student's  performance 
and  the  extent  of  learning;  also  the  material  used  to  evaluate  the 
course  content  and  presentation. 

Courseware,  Guides,  Procedures  -  The  training  program  and  instructions  on 
the  methods  to  conduct  the  training. 

Training  Plans  and  Objectives  -  The  achievement  of  built-in-training  which 
provides  for  on-site  field  training  for  equipment  use  and  maintenance 

Test  Results  -  The  results  of  testing  the  student  in  the  course  material. 

Evaluation  Material  -  The  results  of  the  students  evaluations  of  the  course, 
including  recommendations  for  changes  and  improvement. 


Table  2-13 

DATA  CONNECTIVITY  INDEX  FOR  CONTRACTOR  TRAINING  IDEF  CHART 
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Data  Item 
Information  Input 


From  or  To 


Technical  Specification 
Maintenance  Plan 
Instructional  syste  m 

Design  Requirement 
Design  Description 
LSA  Data 
Technical  Manuals 
R  el  and  M  aint  A  nalysis 
Design  Analysis 


Contract  and  Statement  of  Work 
Preparation  of  Maintenance  Data 
Contract  and  Logistics  Analysis 

Contractor  Specification  and  Engineering  data 

Logistics  Support  Analysis 

Publications  Data 

Logistics  Design  Data 

Engineering  Data 


Information  Output 

Purchase  Orders 
Training  Hardware 

Specifications 
Evaluation  Material 
Test  Results 


Purchasing  activity 

Purchasing  activity  and/or  Design  Engineering 

Logistics  Management 
Logistics  Management 


Controls 

Cost 

Schedule 

Training  Requirements 
Training  Plans  and  Objectives 


Contract  and  Logistics  Management 
Contract  and  Logistics  Management 
Contract  and  Logistics  Management 
Logistics  Management 


Mechanisms 


CAE/CAD 

Com  puter-based  training 

Manual 

Personnel 


Engineering  techniques 
Contractor-owned  or  Government 
furnished  techniques 
Contractor  techniques 
Contractor  techniques 


i 


IDEF  A32,  DESCRIPTION 
CALS  INTERACTION  WITH  TRAINING 


1.  TRAINING  EQUIPMENT  DEFINITION  AND  ACQUISITION 

a.  Current  Status;  Training  equipment  is  presently 
defined  by  individuals  knowledgeable  in  the  methodologies  of 
training  for  the  system  in  question,  and  in  the  results  required. 
They  would  develop  a  plan,  determining  hardware,  software,  and 
procedures;  issue  purchase  requisitions,  specification  and  design 
requirements;  and  make  the  appropriate  arrangements  to  acquire 
all  training  materials. 

b.  Target  System  Characteristics:  In  the  future,  the 

amount  of  built  in  training  will  be  increased  so  the  training 
expert  will  be  defining  the  training  methodology  early  in  the 
design  program.  His  input  will  be  part  of  the  design  process, 
not  after  the  fact.  He  will  be  using  the  CAE  to  understand  and 
define  the  training  aids  and  courseware  needed  to  support  the 
training  process.  A  portion  of  his  requirements  will  be  acted 
upon  by  the  design  engineer  and  designed  and  built  into  the 
system . 

All  orders  will  be  processed  electronically. 

c.  Benefits :  Better  training  programs  will  result  due  to 

an  earlier  integration  with  design.  Built  in  training  will 
increase  the  initial  cost  of  the  hardware  but  will  reduce  later 
training  costs,  maintenance  and  repair  costs,  and  development 
time . 

The  CAE  data  base  of  the  system  will  also  be  a  source  for 
designing  the  training  hardware  and  software  and  will  ensure  full 
compatibility  of  the  training  program  and  its  related  equipment 
with  the  system  design,  even  as  changes  occur. 


d.  Problems  and  Issues:  New  skills  will  have  to  be 

developed  to  create  a  new  Instructional  Engineer,  combining  the 
technologies  of  engineering,  training  and  authoring. 

Additional  memory  and  storage  capabilities  must  be  built 
into  each  system  to  accommodate  the  built-in-training. 

Design  engineers  and  managers  must  be  educated  into  the 
process  and  need  for  this  new  type  of  training. 

Additional  design  and  test  time  may  be  required. 

Additional  up-front  costs  may  be  required  because  of  the 
need  to  integrate  training  with  design,  an  earlier  planning  of 
the  training  program,  and  the  potential  increased  costs  of  memory 

2.  COURSE  DEVELOPMENT 

a.  Current  Status:  A  system’s  training  course  is  now 

planned  and  written  after  the  design  is  completed,  and  usually 
after  the  hardware  is  built.  Actual  hardware  is  used  to  help 
design  the  course  by  running  it  through  its  paces  and  introducing 
faults  and  simulated  situations.  Courses  are  now  developed  for 
either  computer-based  training,  human  interaction,  or  simulation 
techniques  using  actual  hardware. 

b.  Target  System  Characteristics:  Computer-generated 

design  during  the  design  process  will  enable  the  Instructional 
Engineer  to  simulate  faults  and  situations  without  the  necessity, 
in  many  cases,  to  use  actual  hardware.  The  courseware  developed 
could,  where  desirable,  be  integrated  into  the  design  using  the 
data  and  analysis  developed  by  the  Maintainability  and 
Reliability  Engineers.  In  this  way,  the  work  done  by  the 
Instructional  Engineer  in  developing  the  courseware  will  not 
duplicate  the  R&M  efforts  but,  in  fact,  will  integrate  their  work 
into  an  overall  training  program.  The  courseware  would  also  be 
evaluated  using  CAE  technology.  Naturally,  all  written  material 
will  be  on  computer  or  word  processor. 


c.  Benefits :  Early  integration  with  design  will  improve 

both  design  and  instructional  material,  ensuring  course  development 
from  a  common  data  base. 

d.  Problems  and  Issues;  New  skills  will  have  to  be 
developed  to  create  a  new  Instructional  Engineer,  combining  the 
technologies  of  engineering,  training  and  authoring. 

Additional  memory  and  storage  capabilities  must  be  built 
into  each  system  to  accommodate  the  built-in-training. 

Design  engineers  and  managers  must  be  educated  into  the 
process  and  need  for  this  new  type  of  training. 

Additional  design  and  test  time  may  be  required. 

Additional  up-front  costs  may  be  required  because  of  the 
need  to  integrate  training  with  design,  an  earlier  planning  of 
the  training  program,  and  the  potential  increased  costs  of 
memory . 

3.  CONDUCT  TRAINING 

a.  Current  Status:  Computer-based  instruction,  equipment 

simulation,  and  classroom  and  field  training  on  actual  equipment 
are  all  presently  used. 

b.  Target  System  Characteristics:  All  of  the  present 

techniques  described  above  will  be  used.  However,  more  of  the 
data  used  will  come  from  the  digitized  data  and  common  data  base 
of  the  design  program.  In  addition,  built-in-training  will 
provide  the  capability  for  on-site  field  training  for  equipment 
use  and  maintenance.  More  simulation  of  equipment  operation  and 
failures  will  be  done  through  the  digitized  data  base  and  the 
built-in  training.  All  of  the  manuals,  design  analysis,  and 
other  training  aids  will  be  available  to  the  student  in  digitized 
format  to  aid  in  his  training. 


Benefits : 


c . 


More  self-teaching  aids  will  be  available. 


Training  courses  will  be  updated  as  quickly  as  the  design  is 
changed,  and  therefore  kept  current. 


Training  costs  will  be  less. 


More  field  and  on-the-spot  training  will  be  available  to 
more  people. 

Training  will  more  easily  be  focused  to  a  particular  area 
and  to  a  particular  educational  level  when  desired. 


d .  Problems  and  Issues:  The  technology  which  provides 

for  software  being  built  into  each  piece  of  equipment  has  to  be 
developed  and  understood  so  as  to  provide  for  easy  authoring,  as 
well  as  appropriate  training. 

Small,  portable  interface  terminals  need  to  be  developed  and 
be  made  readily  available  at  low  cost. 

Training  technology  has  to  advance  so  as  to  take  advantage 
of  computer-based  information  and  instruction. 

Studies  have  to  be  made  into  new  methods  of  training 
suitable  for  these  techniques. 


IDEF  A32  CONCEPT  PAPER 
CALS  INTERACTION  WITH  TRAINING 


1.  FOCUS  AND  IMPLEMENTATION  CONSIDERATIONS 

1.1  Overview:  As  the  amount  of  electronic  digitized  data  in 

the  design  and  development  of  systems  becomes  greater  and 
greater,  questions  arise  as  to  how  to  best  use  the  data  for 
training  purposes.  This  leads  us  to  consider: 

a.  What  should  training  be  like  in  the  near  future  in 
terras  of  methods,  functions,  and  performance? 

b.  What  data  from  the  design  data  base  would  be 
appropriate  for  use? 

c.  What  new  data  would  have  to  be  generated? 

d.  What  format  should  the  data  and  the  training  activities 
take? 

The  training  that  will  be  considered  encompasses  three  basic 
areas:  maintenance  training;  operator  training;  and  general 

basic  training. 

The  major  technological  innovations  on  the  horizon  will 
affect  the  way  training  is  designed,  developed,  delivered  and 
managed . 

Innovations  which  will  affect  training  will  occur  in 
computer,  video  and  training  technologies.  Computer-related 
advancements  which  will  impact  training  include:  improved  user 
interfaces,  inexpensive  memory,  multi-tasking  machines,  powerful 
handhelds,  and  reasonably  costed  3-T  color  graphics  systems. 
Videodisc  improvements  will  continue  to  happen  coincidently  with 
improvements  in  digital  information  storage.  The  physical  size 
of  discs  will  probably  shrink  while  frame  counts  increase;  sound 
over  stills  will  become  practical  as  will  read/write  and  easily 
reprogrammable  discs;  and  integrated  portable  videocomputer 
devices  will  become  available. 


1 . 2  Projected  Performance  of  the  Target  Computerized  Functions . 

Training  technologies  will  advance  to  take  advantage  of  delivery 
media  improvements.  Artificial  intelligence  (AI)  concepts  will 
be  directly  or  indirectly  applied  to  training,  where  feasible. 
Expert  training  systems  will  be  used  to  provide  instruction  and 
assistance  to  operators  and  maintenance  personnel.  Even  before 
training  technology  advances  to  the  point  where  AI  is  practical, 
the  ideas  and  concepts  of  AI  can  be  incorporated  into  the 
training  environment.  Definitions  of  what  constitutes  training 
will  also  expand  as  systems  are  produced  with  embedded  training. 
Training  aids  incorporated  as  part  of  the  product,  and  automated 
job  aids,  will  be  major  elements  in  the  training  media  mix  of 
the  future. 

The  basic  data  that  will  be  used  to  develop  the  training 
programs  will  come  from  the  engineer's  design  data  base. 

However,  training  experts  will  have  more  and  earlier  inputs  into 
the  design  process,  requiring  equipment  to  be  designed  with  both 
imbedded  and  external  training  as  part  of  the  design  criteria. 

Complex  systems  will  require  either  more  sophisticated 
operators  and  maintainers,  or  will  be  designed  to  support  lower 
aptitude  personnel.  Training  implications  of  design  alternatives 
will  be  a  major  consideration  when  specifying  subsystem 
charateristics.  The  systems  will  probably  incorporate  computer 
technology  as  part  of  each  major  subsystem.  Part  of  the  data 
stored  at  the  subsystem  level  will  be  usable  in  a  training  mode. 
The  "training”  data  may  be  part  of  the  built-in  test  equipment 
(BITE)  and/or  automatic  test  equipment  (ATE)  on  the  system,  or 
they  may  be  accessible  by  the  user  when  training  is  needed.  BITE 
and  ATE  components  will  have  their  functionality  increased  so 
that  more  analysis  and  diagnosis  of  faults  and  recommended 
corrective  procedures  will  be  done  internally  by  the  systems. 

For  example,  systems  will  be  able  to  check  their  own  boards  and 
"tell"  the  maintainers  to  replace  a  specific  faulty  chip  on  a 
particular 
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board.  Also,  if  an  operator  sets  a  dial  to  a  nonstandard 
position,  the  system  will  be  "smart”  enough  to  ask  the  operator 
if  that  is  indeed  the  desired  setting.  When  the  setting  has 
dangerous  effects,  it  will  not  allow  the  setting.  The 
communications  link  between  the  system  and  the  raaintainer  or 
operator  will  be  a  form  of  training  on  future  systems. 

Systems  of  the  future  will  be  designed  and  defined  on 
CAE/CAD/CAM  systems.  The  computer  will  have  a  3-D  description  of 
the  system  in  its  data  base.  A  3-D  graphics-based  training 
system  will  access  the  CAE/CAD/CAM  data  base  to  create  a  training 
simulator  of  the  real  system.  In  the  simulated  system,  accurate 
to  the  level  of  detail  in  the  CAD/CAM  data  base,  the  trainee  can 
safely  learn  and  experiment  with  a  representation  of  the  system. 
The  open  endedness  of  the  simulation  is  based  on  the  capabilities 
of  3-D  graphics  systems  to  do  real-time  motion  with  infinite 
perspectives  of  the  equipment,  and  implementable  AI  knowledge 
representations  which  reflect  how  the  equipment  works. 

A  video  image  of  the  equipment  can  be  presented  from  the 
design  data  base.  Assembly  and  disassembly  can  be  simulated  and 
interactively  operated  by  the  student.  Both  electronic  and 
mechanical  performance  can  be  simulated  under  various  conditions 
to  instruct  the  student  as  to  how  the  equipment  works.  Faults 
can  also  be  introduced  and  repair  procedures  stepped  through. 

This  will  all  be  guided  by  an  interactive  audio-video 
presentation  designed  and  structured  to  teach  the  student  to 
operate  and/or  maintain  the  system  or  equipment. 

LSA  data,  an  offshoot  of  the  design  data  base,  will  also  be 
computer-generated.  This  addition  to  the  data  base  will  then  be 
used  for  the  development  of  the  maintenance  task  analyses  which, 
in  turn,  leads  to  the  training  courseware.  It  forms  the  heart  of 
the  planning  of  the  training  programs  and  will  be  part  of  the 
total  data  base. 


Manuals,  documentation,  and  other  forms  of  job  aids  will 
also  be  nonpaper-based  in  the  future.  Job  aids  will  be  sorted 
digitally  in  the  system  or  in  specially  designed  ATE,  and  can  be 
outputted  as  video,  audio,  text,  and/or  a  combination  thereof. 
Such  job  aids  will  be  available  either  by  user  demand  or  system 
initiation. 

These  job  aids  actually  perform  on-the-job  training  for 
persons  not  familiar  with  the  equipment.  Depending  upon 
complexity,  this  could  allow  persons  not  specifically  trained  in 
a  particular  equipment  maintenance  task  to  perform  that  task  by 
using  the  built-in  computer  aids. 

Equipment  repair  will  be  taught  by  modeling  the  steps  and 
actions  which  have  to  be  taken  by  the  repairer.  In  the 
electronic  manuals  of  the  future,  this  may  take  place  by  having 
the  system  "dump"  video  and  instructional  logic  into  the 
repairman's  portable  integrated  videocomputer.  The  interface  for 
such  a  device  must  include  options  which  allow  for  hands-free 
operation  of  the  training  device  (e.g.,  speech  input/output )  and 
the  repairman.  Systems  operations  training  will,  to  a  great 
extent,  be  resident  on  the  system.  Initial  training  will  be  the 
exception  to  this,  but  even  initial  training  will  be  affected 
(i.e.,  reduced  training  requirements)  by  embedding  operations 
training  in  the  system. 

A  major  area  where  embedded  training  will  only  be  an  adjunct 
is  the  operation  of  complex  systems  which  require  psychomotor 
skills  which  must  be  practiced  in  a  simulator  for  safety  and 
practical  considerations  (e.g.,  weapon  systems).  Embedded 
training  will  require  that  multi-tasking  concepts  be  part  of  each 
subsystem  so  that  the  operator  can  access  training/ job-aid 
materials  while  in  the  process  of  operating  the  equipment.  The 
training  materials  will  be  directly  relevant  to  the  operational 
tasks  being  performed. 

New  forms  of  training  data  will  be  developed  to  use  the  data 
base  generated  in  design.  However,  they  will  be  formatted  to  be 


suitable  for  interactive  instructional  purposes.  A  new  skill, 
combining  the  technologies  of  engineering,  training,  and 
authoring,  will  be  developed  to  put  a  suitable  instructional 
program  together.  Authoring  software  will  also  be  necessary  to 
convert  the  training  methodology  into  electronic  form  suitable 
for  interaction. 

1.3  Implementation  Considerations.  No  amount  of  computer- 
based  instruction,  electronic  simulation,  or  the  like,  will  ever 
replace  the  need  to  have  some  real-time  human  interaction  with  an 
instructor  during  a  major  training  program.  The  human  will  work 
in  conjunction  with  computer-aided  training,  but  as  the  systems 
becomes  larger  and  more  complex,  human  interaction  will  remain  a 
requirement . 

In  addition  to  the  basic  design  data  that  will  be  provided 
for  training,  the  student  will  also  have  access  to  other  data  to 
increase  the  level  of  his  performance.  Such  items  as  IPBs, 
RPSTLs,  reliability  predictions,  and  results  of  other  analysis 
will  be  available  for  his  use  so  as  to  make  his  understanding  of 
equipment  performance  and  maintainability  even  greater.  Major 
innovations  in  training-related  technologies  will  cause  changes 
in  the  way  training  is  delivered  in  the  future.  The  major 
change,  however,  is  not  in  the  mechanics  of  training 
implementation,  but  rather  in  an  extension  of  the  definition  of 
what  constitutes  training.  We  can  be  reasonably  sure  of  the 
advances  in  hardware  and  software  technologies  because  of  the 
large  amount  of  research  and  development  being  conducted  in  both 
the  Government  and  private  sectors.  Similar  significant  advances 
will  have  to  be  made  in  the  training  domain.  Training-related 
research  and  development  is  required  for  improvements  and 
breakthroughs  analogous  to  those  in  other  technologies.  In  order 
for  the  training  community  to  be  ready  to  apply  tomorrow's 
technological  advances  effectively,  investigation  and  further 
development  of  training  theory,  methodologies,  techniques,  and 
approaches  must  be  undertaken  today. 


1.1|  Likely  Payoffs  and  Benefits.  There  are  many  benefits 
envisioned  when  the  training  methodology  utilizes  the  computer- 
based  digitized  data  and  when  it  is  integrated  into  the  design  of 
equipment . 

a.  Better  training  programs  will  result  due  to  an  earlier 
integration  of  the  training  equipment  and  its 
requirements  with  system  design. 

b.  Built-in  training  may  increase  the  initial  cost  of  the 
hardware,  but  should  reduce  later  training  costs, 
maintenance  and  repair  costs,  and  development  time. 

c.  Early  integration  with  design  will  improve  both  design 
and  instructional  material,  ensuring  course  development 
from  a  common  design  data  base. 

d.  More  self-teaching  aids  will  be  available,  and  will  be 
interactive  with  the  student. 

e.  Training  courses  can  be  updated  as  quickly  as  the 
design  is  changed,  and  therefore  kept  current. 

f.  More  field  and  on-the-spot  training  will  be  available 
to  more  people.  Human  interaction  can  be  kept  to  a 
minimum  where  not  required. 

g.  Training  can  more  easily  be  focused  in  a  particular 
area  and  to  a  particular  eductional  level  when  desired. 


1.5  Anticipated  Problems  and  Changes  Needed.  Developing 
integrated  training  by  using  the  computer-based  digitized  data 
will  not  be  easy.  As  a  matter  of  fact,  it  is  close  to  being  a 
revolution  in  training  technology;  very  little  of  it  exists 
today.  Some  of  these  changes  that  are  required  are  as  follows: 

a.  New  skills  will  have  to  be  developed  to  create  a  new 
species  of  Instructional  Engineer,  combining  the 
technologies  of  engineering,  training  and  authoring. 

b.  Additional  memory  and  storage  capabilities  must  be 
built  into  each  system  to  accommodate  the  built-in¬ 
training;  therefore,  low  cost  memory  is  a  must. 

c.  Design  engineers  and  managers  must  be  educated  into  the 
process  and  need  for  this  new  type  of  training. 

d.  Additional  design  and  test  time  may  be  required. 


e.  Additional  up-front  costs  may  be  required  because  of 
the  need  to  integrate  training  with  design,  earlier 
planning  of  the  training  program,  and  the  potential 
increased  costs  memory. 

f.  The  technology  which  provides  for  software  being  built 
into  each  piece  of  equipment  has  to  be  developed  and 
understood  so  as  to  provide  for  easy  authoring,  as  well 
as  appropriate  training. 

g.  Small,  portable  interface  terminals  need  to  be 
developed  and  be  made  readily  available  at  low  cost. 

h.  Training  technology  has  to  advance  so  as  to  take 
advantage  of  computer-based  information  and 
instruction. 

i.  Studies  have  to  be  conducted  for  new  methods  of 
training  suitable  for  these  techniques. 

j.  Development  schedules  will  be  longer  to  accommodate  the 
design,  development  and  test  of  the  training  function. 


2.  IDENTIFICATION  OF  CANDIDATE  FUNCTIONS 

The  whole  concept  of  the  future  of  training  technology  is  how 
it  is  tied  to,  and  integrated  with,  the  design  process.  The  use 
of  the  common  design  data  base  early  in  the  design  process,  and 
influencing  the  design  because  of  training  requirements,  is 
crucial  in  the  development  of  training  in  the  digitized  world.  A 
type  of  system  that  would  most  likely  take  early  advantage  of 
this  new  training  methodology  would  be  an  electro-mechanical 
system  that  will  be  used  by  any  of  the  Services. 

3.  ANTICIPATED  RECOMMENDATIONS 

3.1  Funding  Issues.  Because  integrated  training  is  required 
early  in  the  design  program,  more  up-front  money  will  be  required 
in  procuring  such  a  system.  The  cost  of  a  system  may  also  be 
increased  due  to  the  additional  software  and  hardware  required  to 
make  these  new  training  concepts  operational.  However,  the  life 
cycle  costs  and  future  training  costs  will  decrease.  A  trade-off 
will  be  required  to  justify  the  early  expenditures  as  a  means  of 
reducing  follow-on  costs. 


3.2  Incentive  Issues.  Government’s  incentives  are  to  increase 
system  readiness,  improve  deployability/sustainability,  better 
utilize  manpower  and  to  reduce  long-term  costs.  All  of  these  are 
possible  with  computer-integrated  training.  These  incentives 
must  be  passed  along  to  the  Contractor. 

In  addition,  development  of  these  new  training  technologies 
will  never  happen  unless  the  Government  provides  funds  for 
research  and  development. 

3.3  Contractual  Issues.  The  major  contractual  issues  that 
need  to  be  addressed  include  the  methods  for  specifying,  testing, 
and  accepting  integrated  training.  The  RFP  should  specify  the 
need  and  define  a  method  by  which  training  will  be  imbedded, 
integrated  with  the  design  process,  and  used  in  the  field. 

3.4  Specifications  and  Standards  Issues.  New  standards  and 
specifications  would  be  required  for  this  new  technological 
approach.  These  documents  must  be  coordinated  by  all  Services 
and  must  be  defined  so  as  to  have  appropriate  interfaces  with  all 
the  necessary  peripherals.  At  the  same  time,  standard  interfaces 
with  hardware  and  software  peripherals  need  to  be  defined. 

These  standards  must  be  developed  early  on,  otherwise  chaos 
will  result  with  the  training  equipment  (i.e.,  portable  terminal) 
not  being  able  to  interface  with  the  system  for  which  training  is 
required . 

3.5  Technological  Changes.  The  technological  changes  required 
have  been  discussed  in  paragraph  1.  The  most  important  include: 

Development  of  the  new  training  technology 

Computer-related  advancements 

Improvements  in  the  video  disc  system 


3.6  Policy  Issues.  There  does  not  appear  to  be  any 
significant  Government  policy  issues  that  stand  in  the  way  of 
integrating  training  with  the  design  process  and  its  utilization 
of  computer-aided  technology. 

l».  JUSTIFICATION  FOR  THE  CHOICE  OF  THE  CANDIDATE 

A  small  electro-mechanical  system  should  be  chosen  because 
of  the  capability  to  develop  and  build-in  the  training  programs 
early  in  its  design  phase.  It  would  be  a  system  that  is  fairly 
easy  to  manage,  and  one  where  the  developing  technology  parallels 
the  system  technology. 

For  a  first-time  project,  it  would  probably  be  more  easily 
specified,  tested,  and  evaluated  than,  say,  a  large  weapons 
system.  Yet,  it  would  have  all  the  training  elements  involved. 

Most  design  efforts  in  developing  an  electro-mechanical 
system  are  computerized  now,  so  the  use  of  the  digitized  data 
would  not  be  foreign  to  the  contractor. 

Finally,  the  evaluation  of  the  benefits  could  be  made  more 
easily  and  more  quickly  than  many  other  potential  choices  because 
of  the  relatively  high  visibility  of  all  cost  elements  and  the 
reasonably  short  turnaround  cycle. 


CALS  FUNCTIONAL  DESCRIPTIONS 
CONTRACTOR  FUNCTIONS: 

10.  IDEF  A33,  CALS  for  the  Preparation  of  Maintenance  and  Operation  Data 
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Figure  2-19.  IDEF  A33,  PREPARE  MAINTENANCE  AND  OPERATION  DATA,  CONTRACTOR 
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A33  Prepare  Maintenance  and  Operation  Data 

Industry  incentives  will  be  provided  by  the  continuing  pressure  to 
improve  productivity  and  reduce  costs.  Development  of  a  standard  data 
interchange  format  will  assist  in  directing  industry  investment  toward  a 
systems  that  can  communicate  with  those  of  the  services. 

Near  term  funding  will  be  required  in  order  to  take  advantage  of 
current  industry  investment  plans,  maximize  return  on  investments  being  made 
in  service  systems  and  to  lay  the  foundation  for  longer-term  advances. 
Funding  these  activities  will  require  that  they  be  given  a  high  priority 
within  DOD.  The  fact  that  the  majority  of  savings  to  be  had  in  this  area  is 
in  the  form  of  cost  avoidance  rather  than  cost  savings  will  not  make  its 
funding  any  easier. 

Prioritization  of  funding  should  be  as  follows:  first,  development  of 
near-term  data  exchange  formats,  second,  development  and  implementation  of 
service  systems  to  receive,  distribute,  archive  and  update  computerized 
publication  data,  and  third,  development  and  demonstration  of  data  authoring 
capabilities  for  interactive  maintenance  aids. 

Computerization  of  the  technical  publication  process  offers  high 
payoff  opportunities  in  a  number  of  areas.  The  most  significant  of  these  is 
simply  the  opportunity  to  continue  operations  in  a  reasonable  manner.  The 
process  of  developing,  distributing  and  maintaining  paper  based  technical 
publications  has  become  so  unwieldy  that  its  continued  viability  is  in 
doubt.  The  existing  structures  have  been  stretched  nearly  to  the  breaking 
point  by  increased  page  counts,  higher  costs,  longer  flow  times,  increased 
number  of  publications  and  funding  realities. 

Significant  cost  payoffs  include,  1)  Reduced  (or  contained)  data 
acquisition  costs  through  continued  industry  automation,  2)  Lower  future 
change  costs  through  availability  of  high  quality  electronic  source  data  and 
3)  Improved  weapon  support  through  timely  data  update,  faster  distribution, 
and  reduction  (or  elimination)  of  change  page  insertion. 
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Figure  2-20.  IDEF  A33n,  PREPARE  MAINTENANCE  AND  OPERATION  DATA 


Table  2-15.  IDEF  A33n,  SUMMARY  (sheet  1  of  2) 


A33n  Prepare  Maintenance  and  Operation  Data 

There  are  three  activities  which  describe  the  preparaton  of 
maintenance  and  operation  data.  The  devel opment/updating  of  maintenance  and 
operation  data  is  subject  to  automation  procedures  such  as:  automated 
production,  computer-aided  authoring,  and  de-centralized  production. 

Validation/Verification  of  maintenance  and  operation  data  is  the 
second  activity.  The  current  quality  assurance  functions  for  plate  negative 
deliverables  are  accomplished  through  examination  of  the  completed  product 
for  compliance  with  specification  requirements.  Verification  that 
electronic  data  deliverables  comply  with  requirements  will  mandate 
development  of  new,  automated  methods  for  performing  quality  assurance 
checks. 

The  delivery/archival  of  maintenance  and  operation  data  is  the  third 
activity.  The  emerging  industry  standards  for  a  digital  deliverable  are  the 
GENCODE  and  IGES  standards.  This  standardization,  however,  is  occuring  as  a 
result  of  the  need  to  transfer  graphics  from  CAD  to  publication  systems  and 
to  produce  data  on  a  variety  of  devices  (laser  printer,  typesetter,  etc.) 
without  reformatting  it. 

G1  ossary 

Requirement  Approval  -  Approved  maintenance  requirements  and  planning  -  from 
LSA  function. 

Nomenclature  Assignment  -  Assignment  of  official  Government  nomenclature  to 
an  item. 

Specifications  -  Development  of  suitable  data  delivery  formats  and 
standardization  of  those  formats  throughout  the  services. 

LSA  Data  -  Logistics  Support  Analysis  data. 

Development  Schedules  -  Under  the  restrictions  imposed  by  the  Contract 
Statement  of  Work. 

Engineering  Data  -  Aperture  cards  of  assembly  drawings,  schematic  wiring 
diagrams,  wire  lists,  etc. 

Required  Changes  -  Changes  required  by  virtue  of  design  changes  or 
correction  of  errors. 


Budget/Contract  -  Constraints  due  to  financing  or  contractual  requirements. 
Management  Plan  -  Work  plan  to  accomlish  requirements. 

Development  Status  -  Record  of  design  progress. 

Inprocess  Data  -  Under  the  restrictions  imposed  by  the  Contract  Statement  of 
Work. 


Delivery  Schedules  -  As  specified  by  the  contract. 


Table  2-15.  IffiF  A33n,  SUMMARY  (sheet  2  of  2) 


A33n  Glossary  (Con't) 

Validation/Verification  Requirements  -  Delineation  of  what  is  required  of 
the  contractor  and  Government  to  prove  the  accuracy  and  contractual 
compliance  of  the  material. 

Preliminary  Data  -  Maintenance  and  operation  data  which  has  not  been 
verified  or  validated. 

Hardware/Faci lity/Personel  Availability  -  Schedule  of  resource  availability 
for  maintenance. 

Customer  Verification  Schedules  -  As  specified  by  the  contract. 

Validation/Verification  Results  -  Outputs  from  review  of  the  analyses  and/or 
demon st rati ons. 

Verified  Data  -  Maintenance  and  operation  data  which  has  been  reviewed  and 
validated. 

Customer  Acceptance  -  Approval  of  an  item  to  enable  closure  and  payment. 

Delivery  Status  -  Status  against  specified  delivery  dates. 

Completed  Data  -  Data  that  has  been  completed  and  accepted. 


IDEF  A33,  DESCRIPTION 

CALS  FOR  THE  PREPARATION  OF  MAINTENANCE  AND  OPERATION  DATA 


Current  Status: 

o  Manual  Authoring 

o  Semi-Automated  Production 

o  Plate  Negative  Deliverable 

o  Centralized  Production 

o  Hard  Copy  Distribution 

o  Paper  Delivery  of  Data  to  Users 


Target  System  Characteristics: 

Short  Range 

o  Computer-Aided  Authoring 

o  Automated  Production 

o  Electronic  Deliverable  Format 

o  Electronic  Distribution 

o  De-Centralized  Production 

o  Paper  Delivery  of  Data  to  Users 

Long  Range 

o  Computer-Aided  Authoring 

o  Automated  Production 

o  Highly  Structured  Electronic  Delivery  Format 

o  Electronic  Distribution 

o  On-Demand  Interactive  Delivery 

o  Configuration  and  Skill  Sensitive 


Benefits : 


o 

o 

o 

o 

o 


o 

o 

o 


Short  Range 

Reduced  or  Contained  Data  Preparation/Update  Costs 

Shorter  Update  Flow  Times 

Shorter  Distribution  Flow  Times 

Reduced  Field  Publication  Maintenance  Effort 

Potential  for  Improved  Fault  Isolation  Procedures 

Long  Range 

Improved  Fault  Isolation  Capabilities 

Integrated  Maintenance  and  Training  Data 

Skill  Level  and  Configuration  Sensitive  Presentation 


Problems : 

o  Absence  of  Electronic  Delivery  Formats 

o  Front  End  Funding  for  Standards  Development 

o  Front  End  Funding  for  Development  of  Service  Systems 

o  Printing  and  Distribution  Bureaucracy 

o  Service  Prioritization 


Deliverable  Product  Standardization 
Integration  of  Service  Efforts 

Potential  of  Higher  Long  Term  Data  Preparation  Costs 
Confusion  Concerning  Appropriate  Service  and  Industry 
Roles 


Implementation  Approach: 


o  Integrated  Efforts  of  Services 

o  Develop  and  Implement  Computer  Sensible  Deliverables 
o  Implement  Service  Archive,  Update  and  Distribution 
Systems 

o  Continue  Interactive  Maintenance  Aid  Efforts  of 
Services 

Implementation  Cost: 

o  Detailed  Estimate  Not  Available 

o  Will  be  Higher  if  Effort  is  Not  Initiated  in  Near 
Future 
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IDEF  A33  CONCEPT  PAPER 

CALS  FOR  THE  PREPARATION  OF  MAINTENANCE  AND  OPERATION  DATA 

1.  FOCUS  OF  CALS  IMPLEMENTATION 

1 . 1  Projected  Performance  of  the  Target  Computerized  Func¬ 
tions  .  Industry  efforts  associated  with  preparation  of  weapon 

system  operation  and  maintenance  data  are  currently  directed 
toward  delivery  of  plate  negatives  for  the  printing  of  paper- 
based  technical  publications.  Increasing  labor  and  material 
costs,  coupled  with  competitive  considerations,  have  resulted  in 
modernization  and  automation  of  the  publication  production 
process  by  industry.  The  technology  utilized  in  the  production 
process  has  progressed  from  typewriters,  inked  illustrations  and 
photographic  reproduction  to  wordprocessing,  interactive  computer 
graphics  and  photo-typesetting.  At  the  same  time  that  the 
technology  of  publication  production  has  been  advancing, 
commensurate  improvements  have  been  made  to  their  usability.  In 
response  to  the  increasing  complexity  of  weapon  systems, 
declining  technician  experience,  lower  skill  levels  and  limited 
training  opportunities,  manuals  have  evolved  from  minimally 
illustrated  procedural  documents  to  today's  highly  illustrated, 
human  engineered,  "job  guide",  "new  look"  and  "skill  performance 
aid"  manuals. 

While  automation  of  the  production  process  has  tended  to 
lower  the  cost  of  technical  publication  preparation,  higher  labor 
costs  and  an  increased  volume  of  data  have  tended  to  increase 
them.  The  net  result  of  these  trends  has  been  a  decrease  in  the 
number  of  hours  required  for  preparation  of  a  manual  page  and  an 
increase  in  its  dollar  cost.  This  higher  page  cost,  coupled  with 
the  increased  number  of  pages  required  for  modern  weapon  systems, 
has  substantially  increased  the  total  cost  of  acquiring  technical 
publications. 
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DoD  components  have  experienced  difficulties  similar  to 
those  of  industry  as  the  costs  of  maintaining  and  distributing 
publications  have  risen  along  with  page  counts  and  the  number  of 
publications  that  must  be  supported.  Unlike  industry,  however, 
little  has  been  done  to  modernize  and  automate  the  DoD  technical 
publication  distribution  and  maintenance  process.  Indeed,  the 
very  nature  of  the  deliverable  product  (plate  negatives  that  are 
not  computer  sensible)  has,  to  a  large  degree,  precluded  DoD 
implementation  of  many  of  the  advancements  industry  has  made.  As 
a  result,  the  flow  time  for  delivery  of  manuals  frequently 
exceeds  six  months,  and  backlogs  of  manual  changes  are  such  that 
updates  are  often  restricted  to  mandatory  safety  and  "make-work" 
items.  In  addition  to  the  cost  impact,  these  difficulties  have  a 
corresponding  detrimental  impact  on  weapon  system  readiness. 

DoD  weapon  system  users  also  have  experienced  their  share  of 
difficulties  with  technical  publications.  The  lengthy  flow  time 
associated  with  publication  updates  frequently  results  in 
maintenance  personnel  working  with  out-of-date,  incomplete  or 
incorrect  data.  Insertion  of  change  pages  alone  is  a  significant 
consumer  of  weapon  system  maintenance  man-hours.  However, 
probably  the  most  significant  difficulty  experienced  by  weapon 
system  users  is  the  limited  usefulness  of  paper-based 
publications  as  diagnostic  aids.  Fault  isolation  procedures  are 
generally  developed  early  in  the  life  cycle  of  a  weapon  system, 
when  a  minimum  of  experience  has  been  gained  concerning  failure 
modes  and  maintenance  difficulties.  The  lengthy  update  process 
and  minimal  feedback  of  historical  maintenance  data  serve  to 
further  minimize  their  usefulness.  Attempts  have  been  made  to 
improve  the  usefulness  of  technical  publications  as  diagnostic 
aids,  but  have  generally  proven  to  be  too  expensive  for 
widespread  implementation.  While  of  some  assistance,  improved 
publication  formats  have  not  completely  compensated  for  reduced 
levels  of  maintenance  manning,  lower  skill  levels  and  increasing 
system  complexity.  In  the  final  analysis,  diagnosis 


of  weapon  system  faults  depends  primarily  upon  the  quality  of  a 
weapon  system's  fault  isolation  features  (BIT,  BITE,  ATE)  and  the 
experience  of  the  maintenance  technician. 

In  response  to  these  difficulties,  DoD  has  initiated  a 
number  of  recent  efforts.  Among  the  more  significant  of  these 
are  the  Air  Force  ATOS  (Automated  Technical  Order  System)  and  the 
Navy  NTIPS  (Naval  Technical  Information  Presentation  System) 
projects.  The  ATOS  effort  is  directed  at  implementation  of 
capabilities  similar  to  those  of  industry  for  maintenance  and 
update  of  technical  publications  and  to  serve  as  a  basis  for 
development  of  an  electronic  distribution  system.  The  NTIPS 
effort  is  focused  upon  development  of  improved  concepts  for 
authoring  and  delivery  of  maintenance  and  operation  data. 

Significant  improvements  need  to  be  made  to  both  industry 
and  DoD  technical  publication  activities.  The  limitations  of  the 
plate  negative  deliverable  and  paper-based  distribution  system 
have  been  reached,  both  in  terms  of  affordability  and  weapon 
system  supportabi lity . 

In  the  near  term,  DoD  must  move  from  a  system  based  upon 
paper  pages  to  one  based  upon  electronic  equivalents  of  those 
pages.  This  is  not  to  say  that  paper  will  be  entirely 
eliminated.  Rather,  instead  of  being  printed  by  an  independent 
contractor  and  distributed  from  a  central  location,  it  will  be 
produced  at  a  de-centralized  data  center  or  on-demand  at  the  work 
location.  Implementation  of  this  type  of  system  would  help 
alleviate  many  of  the  difficulties  inherent  in  the  present 
system,  including  high  data  preparation  and  update  costs,  lengthy 
update  flow  times  and  the  need  to  manually  insert  revision  pages. 
In  addition,  reduction  of  the  update  flow  time  and  cost  would 
also  enable  fault  isolation  procedures  to  be  more  useful  through 
timely  incorporation  of  field  experience  into  the  procedures. 

Such  a  system  would  include  the  elements  of  electronic  authoring, 
a  computer  sensible  deliverable  product  and  a  capability  for  DoD 
components  to  archive,  maintain  and  distribute  data  electron- 


ically.  Needed  data  would  be  provided  to  the  user  in  the  near 
terra  through  distributed  data  centers  or  by  print-on-demand 
systems  and  possibly,  in  the  longer  terra  and  at  fixed  locations, 
by  display  on  a  computer  terminal. 

Several  DoD  actions  will  be  necessary  to  implement  such  a 
system.  The  first  of  these  is  to  develop  a  computer  sensible 
technical  publication  delivery  format.  Industry  is  currently 
making  a  significant  investment  in  computer  hardware  and  software 
for  use  in  development  and  production  of  technical  publications. 
This  effort,  however,  is  directed  toward  development  of 
deliverable  plate  negatives  rather  than  electronic  data  sets.  In 
order  to  take  advantage  of  these  contractor  developed  digital 
data  bases,  DoD  must  provide  a  means  for  their  delivery. 
Development  and  imposition  of  a  digital  deliverable  would  also 
provide  an  incentive  for  industry  to  continue  its  investment  and 
move  to  fully  computerized  processes.  DoD  activities  would 
benefit  by  obtaining  the  data  in  a  form  that  would  be  usable  for 
preparing  manual  updates  and  usable  as  source  data  for  subsequent 
procurement  activities.  It  also  could  be  distributed  by 
electronic  means.  The  second  required  action  is  to  implement  DoD 
computing  systems  capable  of  supporting  digital  technical 
publication  data  archive,  udpate  and  distribution  activities. 

The  near-  and  mid-term  actions  discussed  above  should  be  viewed 
as  a  means  of  transitioning  from  paper  to  computer  based 
technical  publications. 

In  the  longer  terra,  the  technology  needed  to  interactively 
present  maintenance  and  operation  data,  assist  with  fault 
isolation  and  provide  training  data  will  soon  be  available.  As 
maintenance  aiding  devices  that  utilize  this  technology  are 
fielded,  the  technical  publications  function  will  evolve  from  one 
of  preparing,  maintaining  and  distributing  paper  technical 
manuals  to  one  of  preparing,  maintaining  and  distributing 
electronic  data  for  these  devices.  In  addition,  these  data  will 
be  structured  around  the  maintenance  task  rather  than  the  book. 
Rather  than  presentation  of  a  printed  page  as  the  usable  element, 


data  will  be  constructed  around  definable  tasks,  such  as  "Landing 
Gear  Removal",  in  order  to  take  maximum  advantage  of  the  new 
medium.  This  will  also  require  redefining  training  and 
maintenance  requirements,  along  with  their  accompanying  DoD 
organizations,  to  take  advantage  of  the  new  delivery  medium. 

Since  the  technology  will  allow  delivery  of  maintenance  and 
training  data  on  the  same  device,  there  will  be  no  visible 
division  between  maintenance  and  training  data.  Unlike  the  near- 
and  mid-term  actions  that  were  discussed  above,  the  benefits  of 
making  the  transition  to  these  interactive  maintenance  aids  will 
come  almost  exclusively  from  operation  and  support  cost  savings 
by  weapon  system  users.  Indeed,  even  with  increased  use  of 
Computer-Aided  Design  and  Logistic  Support  Analysis  data,  it  is 
possible  that  the  costs  of  preparing  data  for  these  devices  will 
be  higher  than  those  associated  with  preparation  of  conventional 
technical  publications. 


Implementation  Considerations. 


1.2.1  Technical  Considerations.  The  primary  near-term 
technical  consideration  in  modernizing  the  DoD  technical 
publication  process  will  be  development  of  a  suitable  electronic 
delivery  format.  Within  industry,  the  emerging  "de  facto" 
standards  for  a  digital  deliverable  are  the  GENCODE  (GENeric 
CODing)  and  IGES  (Initial  Graphics  Exchange  Standard)  standards. 
This  standardization,  however,  is  occuring  principally  as  a 
result  of  the  need  to  transfer  graphics  data  from  CAD  to 
publication  systems  and  to  produce  data  on  a  variety  of  devices 
(laser  printer,  typesetter,  etc.)  without  reformatting.  Their 
suitability  for  use  as  a  deliverable  format  requires  an  in-depth 
examination.  It  is  possible  that,  rather  than  a  single  format, 
several  will  be  required  in  order  to  accommodate  all  of  the 
various  types  of  technical  publications. 

Other  near-term  technical  issues  that  require  consideration 
include  appropriate  equipment  selection  and  configuration  for 
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Service  systems,  validation  of  industry  deliverable  data  formats 
and  translators,  and  development  of  high  resolution  computer 
terminals  capable  of  displaying  conventional  8  1/2"  x  11"  page 
formats . 

Longer  term  technical  issues  include  the  need  to  quickly 
transmit  large  volumes  of  graphics  data,  development  of  methods 
to  author  and  present  data  using  multiple  colors,  development  of 
methods  for  compact  physical  and  electronic  storage  data, 
integration  of  the  various  data  sources  (BIT/BITE,  spares,  CAD, 
LSAR,  etc.)  and  development  of  new  configuration  control  and 
quality  control  techniques.  Of  primary  concern  will  be  the  need 
for  extensive  study  of  user  interaction  with  non-paper 
maintenance  aids.  Data  presentation  techniques,  the  use  of 
color,  video  presentation  and  audio  delivery  must  be  evaluated 
and  an  optimum  mix  of  techniques  selected  to  derive  the  most 
benefits  from  the  new  medium. 


1.2.2  Contractual  Issues.  The  primary  near-term  contractual 
issue  that  must  be  addressed  is  that  of  how  quality  assurance 
functions  will  be  accomplished  for  electronic  data.  Quality 
assurance  functions  for  plate  negative  deliverables  are 
accomplished  through  examination  of  the  completed  product  for 
compliance  with  specification  requirements.  Verification  that 
electronic  data  deliverables  comply  with  requirements  will 
mandate  development  of  new,  automated,  methods  for  performing 
quality  assurance  checks. 

A  secondary  contractual  consideration  will  be  the 
appropriate  means  of  funding  expenditures  for  publication 
automation  when  they  are  contractually  specified.  There  exists 
within  industry  a  significant  amount  of  opinion  to  the  effect 
that  such  costs  should  be  shared  or  matched  by  the  specifing  DoD 
component.  Without  such  provisions,  it  will  be  difficult  for 
small  businesses  and  lower  tier  subcontractors  to  comply  with 
requirements  for  delivery  of  digital  publications  data. 
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A  longer  term  issue  will  be  that  of  developing  a  new  basis 
for  pricing  data  development.  Near-term  activities  will  probably 
continue  to  utilize  the  number  of  manhours-per-page  as  the  basis 
for  pricing.  When  systems  are  fielded  that  present  data  on  an 
interactive  basis,  pages  as  such  will  no  longer  exist.  Some 
other  basis,  such  as  the  maintenance  task,  will  have  to  be 
developed  for  pricing  and  negotiating  contracts. 

1.?.3  Integration  Issues.  Near-term  integration  issues 
include:  development  of  multi-service  electronic  delivery 

formats,  integration  of  publication  requirements  with  the  LSAR 
and  Provisioning  Technical  Documentation  (PTD)  and  integration  of 
publication  requirements  with  CAD/CAM.  In  order  to  minimize  the 
number  of  translating  programs  and  interfaces  that  must  be 
maintained  by  industry  and  DoD,  it  is  important  that  the  number 
of  individual  data  delivery  formats  be  minimized.  Development  of 
a  minimum  number  of  formats  will  require  the  cooperation  of  all 
DoD  components  and  assignment  of  a  DoD  level  office  to  coordinate 
and  manage  their  development.  A  second  issue  is  that  of 
integrating  publications  activities  into  the  LSAR  process. 

Current  LSAR  standards  provide  little  assistance  to  the 
publication  identification  and  development  process.  The  LSAR 
process  needs  to  be  enhanced  to  provide  for  discrete 
identification  of  publication  requirements,  to  relate 
publications  to  particular  maintenance  tasks  and  to  define  the 
relationship  between  LSAR  data,  Provisioning  Technical 
Documentation  (PTD)  and  the  various  Illustrated  Part 
Breakdown/Repair  Part  and  Special  Tool  List  publications. 
Integration  of  publications  and  CAD/CAM  requirements  could 
significantly  reduce  the  amount  of  effort  required  to  develop  and 
update  technical  publications.  Engineering  data  and  publications 
data  have  many  strong  relationships,  but  are  developed  and 
procured  under  separate  standards.  Integration  of  the 
requirements  contained  in  these  standards  would  provide  for 
development  of  engineering  products  that  are  directly  usable  in 


technical  publications.  Schematic  wiring  diagrams  and  wire  lists 
are  two  of  the  areas  where  significant  savings  could  be  made. 

These  near-term  actions  will  form  a  basis  for  integration  of 
the  activities  that  will  be  associated  with  preparation  and 
delivery  of  data  for  use  by  future  interactive  maintenance  aids. 
Data  will  be  both  more  complex  and  more  highly  structured  than 
present  technical  manual  data.  In  order  to  cost  effectively 
develop  and  maintain  this  data  it  will  be  necessary  to  make 
maximum  use  of  data  that  are  developed  as  part  of  the  design, 
manufacturing  and  support  system  development  activities. 
Development  and  implementation  of  the  means  to  integrate  and 
utilize  data  from  these  various  sources  poses  a  significant 
integration  challenge. 

1.3  Likely  Payoffs  and  Benefits.  As  discussed  in  paragraph 
1.1,  near-term  benefits  of  automating  the  DoD  publication  process 
include : 

a.  Reduced  or  at  least  contained  out-year  data  preparation 
and  update  costs  as  a  result  of  continued  automation  of  the 
authoring  and  production  processes  and  the  availability  of  high 
quality  electronic  source  data. 

b.  Shorter  flow  times  for  incorporation  and  distribution 
of  publication  updates  due  to  continued  automation, 
distributed/print-on-demand  data  production  and  electronic 
distribution. 

c.  Reduced  publication  maintenance  effort  by  weapon  system 
users  due  to  a  reduction,  and  possible  elimination,  of  the  need 
to  insert  publication  revision  pages. 

d.  Improved  fault  isolation  procedures  as  a  result  of 
improved  feedback  of  field  experience  data  and  shorter  update 
flow  times. 

Longer-term  benefits  will  be  almost  totally  in  the 
operations  and  support  area  and  will  include: 


a.  Greatly  improved  fault  isolation  capabilities  through 
the  use  of  interactive  troubleshooting  aids. 

b.  Integration  of  training  and  maintenance  data 
preparation  activities  through  utilization  of  a  common  delivery 
medium. 


c.  Ability  to  present  maintenance  data  at  a  level  of 
complexity  appropriate  to  the  skill  level  of  the  maintenance 
technician. 

Other,  less  tangible  benefits  will  include  improved  data 
access,  skill  improvement  through  on-demand  remedial  training  and 
development  of  maintenance  generalists  rather  than  specialists 
(this  will  support  the  various  year  2000  concepts  for  remote  site 
maintenance) . 

1.4  Changes  Needed  and  Problems.  The  changes  that  need  to  be 
made  to  the  DoD  publications  process  are  discussed  in  paragraph 
1.1.  Problems  that  will  be  encountered  in  implementing  them 
include : 

a.  Benefits  will  accrue  primarily  to  weapon  system  users, 
while  implementation  costs  and  difficulties  will  fall  primarily 
upon  weapon  system  developers  and  managers.  In  addition  to  the 
development  effort  and  costs,  implementation  of  the  improved 
capabilities  discussed  in  paragraph  1.1  will  require  that 
significant  changes  be  made  to  present  methods  of  procurement  and 
support,  and  the  organizations  that  perform  them.  None  of  these 
changes  will  provide  any  large  incentive  for  their 
implementation . 

b.  Obstacles  posed  by  the  extensive  bureaucracy  associated 
with  printing  and  distribution  of  paper-based  publications  must 
be  considered.  Printing  and  distribution  activities  for  paper 
based  technical  publications  employ  a  large  number  of  people  in 
the  government  sector  and  are  a  major  source  of  income  for 
independent  printing  contractors.  No  attempt  to  eliminate 
traditional  printing  of  publications  will  be  greeted  with 
enthusiasm  by  either  of  these  parties. 


c.  Development  and  implementation  of  authoring 
capabilities  for  interactive  maintenance  aids  are  going  to 
require  a  significant  investment  on  the  part  of  both  industry  and 
the  Services.  It  is  probable  that,  at  least  initially,  costs  of 
authoring  these  data  will  be  higher  than  those  of  conventional 
publications.  Without  visible  incentives,  it  will  be  difficult 
to  convince  both  industry  and  the  Services  to  implement  these 
capabilities. 

d.  If  action  is  not  taken  in  the  very  near  future  to 
develop  and  implement  data  exchange  standards  for  technical 
publications,  Service  and  industry  systems  will  have  evolved  to 
the  point  that  many  of  them  will  have  to  be  "washed  out"  in  order 
to  implement  such  standards.  This  would  tend  to  increase  the 
normal  tendency  to  object  to  change. 

e.  Resistance  to  integration  of  traditionally  separate 
functions,  such  as  training  data  development  with  maintenance 
data  development,  and  IPB/RPSTL  data  with  Provisioning  Technical 
Documentation  will  be  encountered  on  the  part  of  both  performing 
and  responsible  management  organizations. 

2.  IDENTIFICATION  OF  CANDIDATE  FUNCTIONS 

2.1  Candidates  for  Automation.  Candidate  areas  for  automation 
include,  (a)  industry  publication  development  and  production 
activities,  and  (b)  Service/DoD  archiving,  updating  and 
distribution  systems. 

2.2  Candidates  for  Standardization.  Candidates  for 
standardization  include  publications  data  exchange  formats  (near- 
term),  data  delivery  formats  for  interactive  maintenance  aids 
(long-term)  and  computerized  systems  (including  hardware, 
software  and  media)  for  use  by  the  Services  in  receiving, 
archiving,  updating,  and  distributing  publications  data.  It 
should  be  noted  that  all  service  systems  cannot  be  standardized, 
due  to  different  maintenance  environments . 


However,  this  does  not  mean  that  none  of  the  systems  can  be 
common  or  that  they  cannot  accept  standardized  data  delivery 
formats . 

2.3  Candidates  for  Integration.  As  discussed  in  paragraphs 

1.1  and  1.2.3,  candidate  areas  for  integration  include  data 
exchange  formats,  LSAR/PTD/Publicat ion  interfaces  and  Service 
computing  system  development  activities. 

3.  ANTICIPATED  RECOMMENDATIONS 

3.1  Funding  Issues.  Near-term  funding  will  be  required  in 
order  to  take  advantage  of  current  industry  investment  plans, 
maximize  return  on  investments  being  made  in  Service  systems  and 
to  lay  the  foundation  for  longer-term  advances.  Funding  these 
activities  will  require  that  they  be  given  a  high  priority  within 
DoD.  The  fact  that  the  majority  of  savings  to  be  had  in  this 
area  is  in  the  form  of  cost  avoidance  rather  than  cost  savings 
will  not  make  its  funding  any  easier.  Prioritization  of  this 
funding  should  be  as  follows:  first,  development  of  near-term 
data  exchange  formats;  second,  development  and  implementation  of 
service  systems  to  receive,  distribute,  archive  and  update 
computerized  publication  data;  and  third,  development  and 
demonstration  of  data  authoring  capabilities  for  interactive 
maintenance  aids. 

3-2  Incentive  Issues.  Near-term  industry  incentives  will  be 
provided  by  the  continuing  pressure  to  improve  productivity  and 
reduce  costs.  Development  of  a  standard  data  interchange  format 
will  assist  in  directing  industry  investment  toward  systems  that 
can  communicate  with  those  of  the  Services. 

Near-term  service  incentives  are  more  difficult  to  define. 

As  discussed  in  paragraph  1.4,  to  weapon  system  developers  a.id 
managers,  implementation  of  near-term  capabilities  will  appear  to 
be  simply  additional  costs.  The  only  effective  incentive  for 


them  will  be  a  continuing  high  level  of  management  emphasis  and 
adequate  funding. 

Longer  term  incentives  will  have  to  be  provided  through 
Service  commitment  to  and  funding  of  development  and  fielding 
activities  for  interactive  maintenance  aids. 

3.3  Contracting  Issues.  Contracting  issues  that  must  be 
resolved  include  methods  of  performing  quality  assurance  checks 
on  electronic  data,  desire  on  the  part  of  industry  for  cost 
sharing  on  initial  contracts  where  improved  capabilities  are 
contractually  specified,  development  of  means  for  performing  data 
validation/verification  activities  and  the  ability  of 
small/disadvantaged  business  to  perform  data  preparation  and 
update  activities. 

3.4  Specification  and  Standards  Issues.  Specifications  and 
standards  issues  include  development  of  suitable  data  delivery 
formats,  standardization  of  those  formats  throughout  the  Services 
and  validation  of  their  implementations.  The  issue  of 
standardized  formats  for  all  Services  is  particularly  important, 
as  it  can  minimize  the  number  of  interfaces  and  translators  that 
must  be  developed,  validated  and  maintained. 

3.5  Technological  Changes.  Three  major  technological 
developments  are  expected  to  impact  the  technical  publication 
function  in  the  near  future.  These  developments  include  more 
capable  and  less  expensive  interactive  graphics  systems  (IGS), 
integrated  text  and  graphics  authoring  systems  and  scanning 
capabilities.  The  IGS  advancements  will  work  to  the  near-  and 
long-term  advantage  of  the  publications  function.  IGS  systems 
are  now  available  that  can  significantly  lower  the  cost  of 
developing  and  modifying  graphics  for  use  in  technical 
publications.  In  the  near  future,  lower  cost  IGS  systems  that 
can  exchange  data  with  CAD  systems  will  be  available. 
Implementation  of  these  systems  will  serve  to  further  lower  the 
number  of  man-hours  required  to  produce  a  publication 


page.  Integrated  text  and  graphics  authoring  systems  (known  as 
"what-you-see-is-what-you-get"  or  WYSIWYG  systems)  offer  the 
potential  of  another  significant  improvement  in  manpower  costs. 
Unfortunately,  since  they  are  primarily  oriented  to  development 
of  page  oriented  data,  they  will  work  to  the  disadvantage  of 
efforts  to  implement  authoring  systems  for  development  of 
interactive  maintenance  aid  data.  Scanning  technology  offers  the 
potential  of  an  inexpensive  method  of  "digitizing"  data  that 
exists  only  in  hard  copy  form.  Scanning  capabilities  have 
advanced  rapidly  in  the  last  few  years  and  show  no  sign  of 
slowing  down  in  the  near  future.  Development  of  a  capability  to 
digitize  existing  technical  publications  data  could  significantly 
ease  the  difficulty  of  transitioning  technical  publications 
functions  from  paper  to  digital  mediums. 

In  the  longer  term,  the  development  of  portable,  rugged, 
computers  to  host  interactive  diagnostic  and  data  delivery 
systems  will  be  required. 

3-6  System  Characteristics.  Two  primary  issues  exist  that  are 
related  to  computer  system  characteristics.  These  issues  are 
security  of  classified  material  and  configuration  control  of 
electronic  data.  Security  of  classified  data  when  stored  in  a 
digital  format  (and  especially  when  subject  to  TEMPEST 
requirements)  is  an  obvious  problem.  To  date,  the  means  utilized 
to  overcome  this  difficulty  has  been  to  isolate  the  computer 
system  containing  the  data  and  restrict  access  (both  physical  and 
electrical)  to  it.  Presently,  this  solution  is  merely 
inconvenient.  In  the  future  it  will  be  unacceptable,  as  it  would 
reduce  the  update  and  distribution  advantages  that  automation  of 
the  process  is  intended  to  achieve  for  some  of  the  most  important 
data.  The  second  issue,  that  of  configuration  control,  is  no 
less  important.  In  order  to  effectively  manage  technical  data, 
configuration  control  must  be  maintained.  An  elaborate  system 
for  controlling  the  configuration  of  paper-based  publications  has 
been  developed  over 


the  years.  A  similar  capability  for  digital  publications  data 
will  have  to  be  developed  and  implemented.  In  addition  to 
management  needs,  safety  is  also  a  consideration,  particularly  as 
it  applies  to  maintenance  of  nuclear  weapons. 

3*7  Policy  Issues.  The  following  policy  issues  exist  with 
regard  to  computerization  of  the  technical  publications  process: 

First,  and  probably  the  most  controversial,  is  the 
appropriate  role  of  government  activities  in  the  creation  and 
update  of  technical  publications  data.  There  is  considerable 
concern  within  industry  that,  in  order  to  justify  the  existence 
of  Service  computing  systems  associated  with  technical 
publications,  the  traditional  role  of  industry  in  preparing  and 
updating  technical  publications  will  be  taken  over  by  the 
Services.  At  the  opposite  end  of  the  spectrum,  some  in  industry 
have  suggested  that  DoD  should  contract  for  all  data  development, 
maintenance  and  access,  thereby  avoiding  the  need  to  develop  any 
organic  data  maintenance  capabilities. 

The  second  policy  issue  that  must  be  addressed  is  that  of 
the  appropriate  role  of  the  GPO  and  independent  printing 
contractors  as  the  Services  make  a  transition  from  paper  to 
computer-based  technical  publications.  Clearly  this  transition 
is  going  to  reduce,  and  eventually  eliminate,  their  traditional 
roles. 

Prioritization  of  publications  system  improvements  within 
the  Services  is  the  third  significant  policy  issue.  As  discussed 
in  previous  sections,  it  will  be  necessary  for  the  Services  to 
commit  a  significant  amount  of  funding  to  making  the  paper-to- 
digital  media  transition.  In  light  of  the  traditional  reluctance 
to  make  support  improvements  a  high  priority,  it  will  probably  be 
necessary  to  develop  and  implement  some  high  level  policy 
direction  in  this  regard. 

A  fourth  issue  will  be  the  need  for  integration  of  the 
various  Service  efforts,  in  order  to  minimize  the  number  of 
interfaces  between  them  and  industry.  Lack  of  standardized 


interfaces  will  add  to  the  cost  of  computerizing  the  publication 
process  and  impede  transfer  of  data  between  the  various  systems. 

Effective  feedback  of  field  experience  into  publications  is 
an  issue  that  each  Service  will  have  to  establish  as  a  priority. 
The  opportunity  to  improve  publications  usability  will  be 
provided  through  reduced  (or  at  least  contained)  update  costs  and 
shorter  flow  times.  These  advantages  can  only  be  capitalized 
upon  if  each  Service  puts  into  place  an  effective  program  of 
field  experience  feedback,  analysis  and  incorporation.  This, 
more  than  any  other  consideration,  will  determine  the  near  term 
usefulness  of  publications  as  fault  isolation  aids. 

4.  JUSTIFICATION  FOR  THE  CHOICE  OF  CANDIDATES 

4.1  High  Payoff.  Computerization  of  the  technical  publication 
process  offers  high  payoff  opportunities  in  a  number  of  areas. 

The  most  significant  of  these  is  simply  the  opportunity  to 
continue  operations  in  a  reasonable  manner.  The  process  of 
developing,  distributing  and  maintaining  paper-based  technical 
publications  has  become  so  unwieldy  that  its  continued  viability 
is  in  doubt.  The  existing  structures  have  been  stretched  nearly 
to  the  breaking  point  by  increased  page  counts,  higher  costs, 
longer  flow  times,  increased  number  of  publications  and  funding 
realities.  As  discussed  in  previous  paragraphs,  significant  cost 
payoffs  are  also  available.  These  payoffs  include  (1)  reduced 
(or  contained)  data  acquisition  costs  through  continued  industry 
automation,  (2)  lower  future  change  costs  through  availability  of 
high  quality  electronic  source  data,  and  (3)  improved  weapon 
support  through  timely  data  update,  faster  distribution,  and 
reduction  (or  elimination)  of  change  page  insertion. 

4.2  Feasibility.  The  feasibility  of  computerizing  the 
technical  publications  function  is  not  in  doubt.  The  majority  of 
the  technology  needed  to  make  near-term  improvements  is  mature 
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and  available  either  off-the-shelf  or  with  little  development. 

Its  cost-effectiveness  is  demonstrated  by  the  considerable 
implementation  of  computerized  capabilities  that  has  already 
occured  within  industry,  and  the  number  of  Service 
development/feasibility  demonstrations  that  are  underway.  The 
primary  challenges  will  be  the  integration  of  the  necessary 
capabilities  into  appropriate  hardware  and  software  packages. 

The  decision  is  not  one  of  whether  improvements  are  feasible,  but 
one  of  how  they  should  be  implemented.  Implementation  is 
currently  in  progress,  what  is  needed  is  DoD/Service  focusing  and 


direction  of  the  effort, 


J|.3  High  Leverage.  High  leverage  of  this  activity  is 
available  due  to  the  significant  investment  that  industry  has 
made  and  is  planning  to  continue.  Additional  leverage  is 
provided  by  the  ability  to  integrate  much  of  the  effort  that  is 
being  accomplished  as  a  part  of  the  various  Service  efforts. 


mmm 


r.v.ir.irawi',1 


mm® 


PERFORM  TEST  AMD  EVALUATION,  CONTRACTOR 


Table  2-1 6.  IDFF  a SUMMARY 


A34  Perform  Test  and  Evaluation 

Glossary 

Contractor  -  The  agency  that  built  the  Item  being  tested. 

Specifications  -  Contractual  performance  and  test  requirements. 

Personnel  -  Test  personnel. 

Resources  -  The  tools,  test  equipment,  facilities  etc.  required  for  test  and 
evaluati on. 

Test  Plan/Procedures  -  Formal  plans  and  procedures  for  the  conduct  of  test 
and  evaluation. 

Government  Reps.  -  Personnel  representing  the  Government  to  monitor  and/or 
conduct  the  tests. 

Test  Data  Results  -  Documented  results  of  the  tests. 

Environmental  V&V  -  Results  of  validating  and  verifying  operation  and 

maintenance  procedures  to  address  various  environmental  conditions. 

Personnel,  Logistics  Support,  Hardware,  Software  -  Test  resources. 

Test  Reports  -  Contractual  documentation  containing  the  test  results. 

Usually  a  formally  specified  data  items. 


IDEF  A34  CONCEPT  PAPER 
CALS  UTILITY  FOR  TEST  AND  EVALUATION 


1.  FOCUS  OF  CALS  IMPLEMENTATION 

1.1  Overview.  To  satisfy  a  Government  requirement,  the 
contractor  must  demonstrate  that  the  proposed  approach  satisfies 
the  needs  of  the  contract.  This  is  accomplished  through  various 
test  and  evaluation  efforts.  The  two  areas  in  which  the 
contractor  directly  participates  in  the  testing  of  the  proposed 
equipment  are  the  contractor's  own  test  and  evaluation  and  the 
procuring  activity’s  technical  evaluation.  The  contractor's  test 
and  evaluation  consists  of  two  efforts:  he  is  required  to 
demonstrate  that  the  system/equipment  will  satisfy  the 
environmental  requirements,  as  desribed  in  the  specification,  and 
he  must  perform  complete  functional  testing  which  is  intended  to 
prove  that  the  system/equipment  does,  in  fact,  operate  as 
required.  The  technical  evaluation  performed  by  the  procuring 
activity,  in  which  the  contractor  also  participates,  is 
essentially  a  functional  test  in  a  dynamic  environment. 

The  testing  efforts  should  be  synthesized  early  in  the 
design  cycle  to  ensure  that  the  logistics  efforts  are  properly 
integrated,  specifically  in  the  areas  of  diagnostics, 
reliability,  and  maintenance.  Ideally,  the  contractor  will  use 
Computer-Aided  Design  with  the  application  of  artificial 
intelligence  to  exercise  the  design  on  the  system/equipment  level 
in  order  to  determine  if  any  system-related  software/hardware 
interface  problems  exist.  With  artificial  intelligence 
computers,  the  design  will  be  stressed  against  the  system 
requirements  and  any  shortcomings  will  be  identified.  These 
shortcomings  will  be  synthesized  by  the  computer  and  recom¬ 
mendations  on  what  corrective  action  should  be  taken  will  be 
identified.  This  approach  will  be  from  the  printed  circuit  board 
level,  through  the  assembly,  all  the  way  up  to  the  system  level. 


This  approach  will  be  used  to  interact  with  failure  modes  and 
criticality  effects  analysis  and  sensitize  the  design  to  stress 
all  of  the  critical  components  in  order  to  determine  the  failure 
impact.  It  also  will  be  used  to  assess  risk  in  compliance  with 
specified  requirements. 

The  deliverables  normally  required  by  a  contract  include  a 
complete  set  of  test  plans  and  procedures.  These  will  also  be 
generated  by  the  computer  using  the  inherent  knowledge  created 
while  designing  and  modifying  the  equipment/system.  The 
appropriate  formats  for  the  plans  and  procedures  will  reside  in 
the  computer  and,  when  initiated,  be  prepared  in  hard  copy  and 
available  for  review.  This  review  will  be  performed  initially  by 
the  contractor  and  then  transmitted  by  computer-to-computer  to 
the  developing  agency  for  review.  Once  approved,  the  developing 
agency  would  transmit  its  comments  back  to  the  contractor  via  the 
computer  link. 

During  the  actual  quality  assurance  testing,  the  computer 
will  simulate  all  of  the  proper  signals  required  to  exercise  the 
machine  to  determine  any  shortcomings  in  the  design.  These  test 
signals  will  then  be  created  for  the  test  environment.  Any 
ambiguities  found  by  these  tests  as  monitored  by  the  computer 
also  will  be  reported.  All  workarounds  and  self-healing 
techniques  will  be  exercised  to  ensure  that  the  built-in  tests 
can  be  successfully  completed.  A  report  will  then  be  computer¬ 
generated  and  forwarded  to  the  developing  agency  for  review. 

1.2  Likely  Payoffs  and  Benefits.  Several  immediate  benefits 
would  be  realized  using  this  application.  There  will  be 
immediate  recognition  by  the  contractor  of  possible  problems  that 
can  occur  during  the  design  and  development  testing  of  the 
system/equipment.  Techniques  to  determine  reliability  weak 
points  may  then  be  exercised  and  rapid  corrective  action  taken  to 
satisfy  the  supportability  requirements.  Failures  that  occur 


during  testing  will  be  rapidly  identified  and  the  degree  of 
impact  measured  so  that  actual  system  performance  can  be 
determined.  All  types  of  signals  could  be  employed  and 
variations  in  design  determined  prior  to  testing  in  a  live 
environment.  The  subjective  evaluations  by  Government  and 
industry  will  be  minimized  and/or  eliminated  and  disputes  on 
system  successes/failures  would  be  nonexistent.  The  benefits  of 
such  a  system  can  include: 

a.  Diagnostics  will  be  performed  and  thoroughly  checked 
out  prior  to  complete  system  design,  thereby 
eliminating  costly  redesign  and  remanufacture. 

b.  Standardized  formats  for  all  test  plans  and  procedures 
will  be  ensured. 

c.  Techniques  to  test  the  system  will  be  based  upon  the 
smart  computer  system  engineering  systems  approach 
developed  at  the  onset  of  the  program  rather  then 
attempting  to  generate  a  document  that  does  not  fully 
satisfy  the  contract  requirements. 

d.  System  design  history  would  be  readily  available  and 
accessible  for  use  in  design  evaluation. 

e.  Future  designs  of  similar  requirements  will  be  enhanced 
as  new  components  are  integrated  to  replace  obsolete  or 
out  of  production  devices.  Rapid  system  quality 
determination  also  will  be  a  major  logistics  benefit. 
The  computer  would  be  capable  of  recognizing  logistics 
shortfalls,  reviewing  the  LSAR  to  ensure  that 
appropriate  parts  are  ordered,  making  changes  to  the 
technical  manuals  and  training  materials,  and  making 
necessary  changes  to  the  maintenance  approach. 


1.3  Changes  Weeded  and  Anticipated  Problems.  Currently,  on¬ 
line,  real-time  testing  capabilities  in  new  systems  are  usually 
not  available  at  the  time  of  quality  assurance  testing.  Nor  have 
the  candidate  systems  been  adequately  analyzed  to  ensure  that  as 
many  problems  as  possible  have  been  identified  and  designed  out 
of  the  system.  Faster  computer  processing  is  required  plus 
additional  capability  for  designing  and  implementing  back  ups, 
workarounds,  and  similar  techniques. 

Standardization  to  provide  software  interfaces  which  will 
ensure  the  availability  of  compatible  global  data  communications 


is  required  so  that  problems  encountered  during  technical 
evaluations  may  be  addressed  in  real  time. 

2.  IDENTIFICATION  OF  CANDIDATE  FUNCTIONS 

Computer-developed  test  procedures  should  be  employed  for 
the  test  and  evaluation  program.  This  would  serve  to  validate 
procedures  as  well  as  equipment;  the  procedures  should  then  be 
used  in  the  technical  manuals. 

3.  ANTICIPATED  RECOMMENDATIONS 

3.1  Funding  Issues.  In  order  to  successfully  adapt  CALS  to 
government  T&E,  testing  requirements  must  be  integrated  with 
budgeting  and  financing  procedures.  Methodologies  for  accurate 
and  early  T&E  cost  forecasting  are  required  and  a  formal 
feasibility  study  of  the  automation  of  DT&E/OT&E  test  procedures 
should  be  undertaken  as  soon  as  possible. 

3-2  Incentive  Issues.  Accelerated  development  of  CALS  for  T&E 
requires  funding  for  exploratory  development  of  T&E  areas 
requiring  state-of-the-art  advancement  and  for  concept 
formulation  efforts. 

3-3  Contracting  Issues.  The  major  contracting  issues  will 
result  from  the  use  of  obligatory  standard  computerized  Support 
Acquisition  and  Management  techniques  which  will  impact  upon 
contractual  regulations.  The  Government  should  be  able  to  gain 
the  necessary  competitive  leverage  with  the  potential  contracting 
sources  by  invoking  a  requirement  for  automated  Test  and 
Evaluation  procedures  on  certain  specific  Requests  for  Proposals 
(RFPs).  Although  there  are  other  methods,  this  would  probably  be 
the  most  cost-effective  means  to  provide  the  necessary  incentive 
for  contractors  to  adopt  CALS  techniques.  It  also  should  be  the 
most  direct  and  timely  alternative  which  the  Government  can 
employ  to  use  CALS  to  improve  T&E  procedures. 
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3 . 4  Specifications  and  Standard  Issues.  Specifications  and 
standards  issues  must  be  addressed  at  the  outset  to  prevent  a 
proliferation  of  independent,  standalone  models--a  condition 
which  would  inhibit,  if  not  prevent,  interoperability  among 
potential  users.  One  way  to  ensure  compatibility  will  be  to 
retain  the  manual  procedures  for  T&E  while  transitioning  to  CALS. 
This  will  permit  existing  specifications  and  standards  to  be 
modified/adjusted  concurrent  with  the  preliminary  development  of 
automated  programs.  This  also  will  allow  the  Govrnment  to  obtain 
the  maximum  utilization  from  the  numerous  "personal  computers" 
already  in  use,  while  transitioning  into  the  networking  of 
computers . 

3-5  Technological  Changes.  The  projected  advances  in  computer 
technology,  data  management  and  exchange  techniques,  and 
communications  methods  should  encourage  the  rapid  introduction  of 
an  automated  Test  and  Evaluation  support  concept  for  both 
Government  and  industry. 

3.6  Policy  Issues.  Government  imposition  of  contractual 
obligation  on  industry  to  comply  with  approved  standards  for 
system  development  is  now  an  accepted  provision  of  DOD  policy. 
Therefore,  requiring  industry  to  implement  standard  computerized 
T&E  support  techniques  during  systems  development  should  not 
require  any  significant  modification  to  the  DOD  systems 
acquisition  policies. 

4.  JUSTIFICATION  FOR  THE  CHOICE  OF  CANDIDATES 

4.1  High  Payoff.  The  T&E  candidates  for  automation  will 
provide  the  opportunity  for  substantial  cost  benefits  in  terms 
of : 

paper  reduction, 

improved  data  accuracy,  and 

improved  data  availability. 
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Cost  benefits  in  paper  reduction  alone  will  justify 
automating  T&E  procedures  for  systems  support.  In  addition  to 
the  savings  by  reducing  and/or  eliminating  reports,  plans,  etc. 
a  potential  exists  for  significant  reduction  in  the  cost  of 
filing  and  sorting  paper  documents. 

4.2  Feasibility.  The  concept  of  fully  automated  techniques 
for  T&E  procedures  is  well  within  the  realm  of  functional 
feasibility,  given  the  present  state-of-the-art  electronic  data 
processing  technologies. 


Table  2-17.  IDEP  A 35,  SUMMARY 


\35  Perform  Manufacture 

The  primary  input  is  "Procurable  Items"  -  the  things  that  are  bought 
or  given  to  the  manufacturer  (e.g.,  sheet  metal  or  engines),  to  be 
incorporated  In  the  output  or  used  in  its  manufacture  (drills).  Implicit 
also  is  the  sum  total  of  previous  knowledge  which  will  be  used  in  decision 
making. 

The  primary  control  is  the  product  design,  and  the  primary  outputs  are 
the  product  themselves.  Support  systems,  parts  and  prototypes. 

Other  controls  are  the  manufacturing  requirements  and  the  management 
directives,  corresponding  reports.  To  unclutter  the  subsequent  diagrams, 
the  "Directives/Reports"  arrows  are  not  drawn,  but  must  be  understood  to  be 
present.  The  parentheses  at  the  arrow  head  show  this  implicit  existence. 

The  primary  output  is  the  product  and  other  manufactured  items  (parts, 
kits,  prototypes).  Other  outputs  are  information  useful  to  planning,  field 
support,  and  design. 
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Table  ?-l8.  IEEF  A35n,  SUMMARY  (sheet  1  of  2) 


A35n  Perform  Manufacture 


There  are  two  "planning"  activities  shown  on  A35;  Box  A351  "Plan  for 
Manufacture"  and  Box  A353  "Plan  Production".  The  first  relates  to  the 
strategy  of  producing  the  total  product  -  the  major  subdivision  of  the 
equipment  structure,  the  basic  method  of  manufacture,  and  the  trade-offs  to 
optimize  facilities  requirements,  cost,  and  time  schedules.  The  second 
relates  to  the  strategy  of  producing  the  individual  parts  -  the  route 
sheets,  operation  sheets,  and  the  list  of  machine  tools,  forms  and  cutters, 
fixtures  and  gauges  required. 

There  are  two  "provisioning"  activities  shown  on  A35;  Box  A354 
"Provide  Production  Resources"  -  facilities,  equipment,  tools,  and  people; 
and  Box  A355  "Obtain  Manufacturing  Materials"  -  those  items  which  will 
ultimately  be  included  in  the  delivered  product. 

There  is  an  administrative  activity;  Box  A352  "Make  and  Administer 
Schedules  and  Budgets".  This  activity  produces  those  schedules  and  budgets 
which  provide  proper  coordination  between  the  separate  activities  of  Boxes 
A353,  A354,  A355,  and  A356. 

Finally  there  is  "Produce  Product".  This  is  where  the  form  and 
character  of  materials  are  altered  and  the  pieces  assembled. 


Glossary 


Product  Design  -  Includes  both  preliminary  and  final  engineering  design. 

The  preliminary  engineering  design  as  well  as  the  final  is  available 
to  Box  1.  The  engineering  release  Itself  and  change  orders  are  used 
for  Box  3  planning  production.  The  Engineering  Design  also  includes 
identification  of  long  lead  items  for  which  early  procurement  is 
requi red. 

Product  Manufacturing  Requirements  -  Includes  the  date  and  rate  of  delivery 
requirements  as  well  as  requirements  on  how  to  obtain  things.  The 
dates  of  delivery  are  needed  for  schedules  or  budgets  and  the  other 
requirements  are  used  for  the  manufacturing  plan  (Box  1). 

Manufacturing  Plans  -  These  are  overview  plans  which  Include  flow  sequence 
plans,  item  and  station  charts,  item  indentures,  facilities  and 
equipment  requirements,  manpower  requirements,  tooling  requirements, 
material  requirements,  etc. 

Material  Plan  -  A  plan  for  acquisition  of  all  of  the  different  things  that 
must  be  procured  to  go  into  the  product,  including  general  principles 
as  well  as  specific  items. 

Schedules  -  These  phasing  of  production  plans,  resources,  materials,  and 
production  itself.  These  schedules  accomplish  the  coordination  of 
Boxes  3,  4,  5,  and  6  and  allow  them  to  operate  essentially 
Independently.  The  schedules  typically  include  start  and  completion 
dates  for  major  Items  dealt  with  by  each  subfunction. 

Budgets  -  The  allocations  of  funds  for  each  of  the  major  sub-activities. 
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Special  Schedule  Requirements  -  Most  items  are  scheduled  according  to 

standard  flow  times.  Any  deviation  from  that  is  a  special  schedule 
requi rement. 

Special  Tool  Identification  -  The  identification  of  tools  that  are  needed 
and  the  part  for  which  they  are  needed. 

Manufacturing  Indentured  Parts  List  -  The  completion  or  extension  of  the 
manufacturing  parts  list  as  produced  by  production  planning.  It  is 
primarily  needed  for  scheduling  purposes  (among  other). 

Resource  Characteristics  -  The  characteristics  and  capabilities  of  the 
facilities,  the  equipment,  people  which  are  available  or  specially 
obtained  for  this  product. 

Production  Instructions  -  The  detailed  description  of  the  operations  and 
processes  that  must  be  carried  out  to  produce  any  given  item, 
including  the  routing  in  which  they  are  to  be  carried  out. 

Procured  Item  Specification  -  Detailed  specification  of  any  item  which  is  to 
be  obtained  from  outside  of  the  company. 

Tools  Specification  -  The  detailed  specification  of  a  tool  (which  must  be 
procured  or  fabricated)  to  be  used  in  producing  the  product. 

Purchase  Requisition  (as  shown  in  Box  4-5)  -  Are  requisitions  to  obtain 
items  to  be  used  in  making  of  facilities,  equipment  or  tools. 

Stores  Requisitions  (from  Produce  Product)  -  Are  the  requisitions  (1)  for 
materials  obtained  to  be  used  in  making  the  product  or  of  resources 
particularly  requisitioned  or  (2)  for  tools  for  making  the  product. 
These  are  requisitions  for  the  item  to  be  supplied  as  opposed  to  being 
obtained. 

Manufacturing  -  The  conversion  of  a  design  into  a  finished  product. 

Manufacturing  then  Includes  planning,  scheduling,  and  getting  whatever 
necessary  for  the  actual  making  of  the  product. 

Production  -  The  actual  making,  the  physical  act  of  doing  what  is  necessary 
to  make  the  product.  Includes  altering  the  form  of  materials, 
assembling,  and  testing. 
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IDEF  A36  CONCEPT  PAPER 


PROVIDING  A  LOGISTICS  SYSTEM 

1.  FOCUS  OF  CALS  IMPLEMENTATION 

1 . 1  Projected  Performance  of  the  Target  Computerized  Functions 

Future  support  planning  and  acquisition  activities  will  not  func¬ 
tionally  differ  in  any  significant  manner  from  those  of  the 
present.  Rather,  the  differences  between  present  and  future 
activities  will  be  the  high  degree  of  integration  between  the 
various  activities,  their  integration  with  the  design  process, 
the  interactivity  of  their  processes  and  the  degree  of  their 
automation . 

Support  system  development  activities  will  be  accomplished 
with  the  use  of  computerized  models  that  are  capable  of 
interacting  with  the  user,  other  support  analyses,  various 
government  data  sources  and  with  the  design  process.  The  result 
will  be  development  of  improved  support  strategies  and  improved 
feedback  of  support  requirements  into  the  design  process.  The 
ability  to  access  and  utilize  various  government  data  sources 
during  this  process  will  also  assist  in  the  process  of  developing 
support  systems  and  strategies  that  more  closely  fit  the  system 
user.  Interactive  models  will  also  allow  alternative  support 
strategies  to  be  quickly  evaluated. 

Once  the  most  appropriate  support  system  strategy  has  been 
selected,  the  LSAR  data  base  will  automatically  be  structured 
based  on  the  repair  level  and  repair/discard  decisions  made 
during  the  support  system  development  process.  Data  from  other 
support  analyses,  design  activities,  industry  data  bases  and 
government  data  bases  will  also  be  automatically  or  semi- 
automatically  loaded.  Manual  addition  or  manipulation  of  LSAR 
data  will  be  kept  to  a  minimum,  but  where  necessary  will  be 
performed  in  real  time  on  an  interactive  basis.  The  outstanding 
features  of  future  LSAR  data  systems  will  be:  (1)  their  ability 


to  relate  to  and  interact  with  design  data  through  a  common 
indexing  structure,  (2)  rather  than  being  in  addition  to  other 
logistics  planning  data  requirements,  they  will  be  the  logistics 
planning  data  (thus,  rather  than  acquiring  PTD,  3ERDS,  LSAR, 
etc.,  only  LSAR  data  would  be  acquired),  (3)  users  of  the  LSAR 
data  (including  DoD  components)  will  access  needed  data  directly 
from  an  on-line  data  system  rather  than  by  requesting  hard  copy 
reports,  and  (4)  instead  of  being  all  encompassing,  LSAR  data 
requirements  will  be  tailored  to  the  item  or  system  being 
procured . 

As  a  result  of  the  reduced  flow  times  and  improved  usability 
of  the  support  system  planning  and  LSAR  data,  support  acquisition 
activities,  including  technical  publications  development,  the 
instructional  system  development  process,  spares  provisioning 
activities,  support  equipment  specification  development, 
development  of  facilities  design  criteria  and  transportability 
analysis  will  obtain  their  requirements  directly  from  the  LSAR 
data  base. 


1 . 2  Implementation  Considerations. 

1.2.1  Technical  Considerations.  It  is  presently  possible  to 
model  and  simulate  the  operation  of  various  support  strategies 
and  support  system  configurations  using  high-order  computer 
simulation  languages  and  powerful  mainframe  and  super  mini¬ 
computer  hardware.  These  tools  can  be  of  great  benefit  when 
properly  utilized.  Their  deficiency  is  that  they  are  stand 
alone,  frequently  are  not  interactive,  are  manpower  intensive  and 
time  consuming  to  develop  and  expensive  to  utilize.  Improvement 
of  support  system  design  and  trade-off  activities  will  require 
that  these  techniques  be  integrated  with  other  design  and  support 
analyses,  that  they  be  made  interactive  with  the  user,  that  the 
cost  and  difficulty  of  developing  and  using  them  be  lessened,  and 
that  the  means  be  developed  for  them  to  exchange  data  with  the 


design  and  LSAR  functions.  Implementation  of  improved  modeling 
and  simulation  capabilities  will  do  for  support  system  design 
what  spreadsheet  programs  have  done  for  business  management: 
allow  near  real-time,  interactive  evaluation  of  various 
alternatives.  Making  them  interactive  with  the  design  process 
will  allow  for  near  simultaneous  optimization  of  design  and 
support  system  configurations.  Areas  that  pose  significant 
technical  challenges  include  (1)  development  of  appropriate 
modeling  algorithms,  (2)  development  of  even  higher  level 
simulation  languages,  and  (3)  development  of  mechanisms  to 
interface  support  system  models  with  other  support  analyses  and 
the  design  process. 

Integration  and  interaction  of  support  system  development 
and  acquisition  activities  with  those  of  the  design  process  will 
require  that  some  means  be  developed  to  relate  the  various  types 
of  support  data  to  each  other  and  to  the  design  process.  The  two 
factors  that  must  be  addressed  in  order  to  do  this  are  data 
formats  (number  and  type  of  characters)  and  data  structures 
(indexing).  One  concept  for  doing  this  has  been  advanced  by  the 
Air  Force  with  its  Functionally  Integrated  Designating  Reference 
(FINDER)  concept.  Without  this  common  indexing  structure,  it 
will  be  impossible  to  obtain  and  relate  data  from  all  of  the 
various  sources. 

Improvement  of  the  LSAR  development  process  will  require 
that  all  of  the  LSAR  data  be  automated  and  that  the  processes 
associated  with  its  development  and  update  be  both  interactive 
with  the  analyst  and  occur  at  near  real  time.  On-line  LSAR  data 
systems  have  been  developed  in  the  past,  but  have  generally  been 
oriented  toward  development  and  delivery  of  hard  copy  LSAR 
products,  rather  than  the  on-line  delivery  of  information,  and 
the  preparation  of  the  complete  range  of  logistics  data 
requirements.  The  expense  associated  with  establishment  and 
operation  of  these  on-line  systems  (which  are  usually  mainframe 
computer  based)  has  to  a  large  degree  precluded  their  use  by 


second  and  third  tier  DoD  suppliers.  Interactive,  real  time  LSAR 
systems  must  be  developed  and  implemented.  Along  with  this,  a 
means  must  be  developed  to  provide  second  and  third  tier 
suppliers  with  access  to  these  capabilities.  The  most  obvious 
way  to  do  this  would  be  through  the  development  of  LSAR  systems 
that  utilize  mini/micro  computer  technology  and  possibly  fourth 
generation  languages  rather  than  mainframe  computers  and  second 
or  third  generation  languages. 

Computer-aided  processes  for  use  in  accomplishing  the 
various  support  acquistion  functions  will  also  have  to  be 
developed.  Some  efforts  have  been  made  to  automate  processes 
within  these  functions,  but  little  attention  has  been  directed  at 
their  standardization  or  integration  with  the  LSAR.  In  addition, 
the  majority  of  the  internal  process  automation  has  been  of  batch 
or  transaction  oriented  methods  rather  than  on-line,  interactive 
capabilities. 

Data  security  for  classified  data  will  also  be  a  significant 
technical  issue  that  must  be  dealt  with. 

1.2.2  Contractual  Issues.  Contractual  issues  will  center 
primarily  around  the  cost  of  developing,  implementing  and 
supporting  the  improved  capabilities  that  are  described  in 
paragraph  1.1.  To  the  extent  that  they  are  perceived  by  industry 
as  a  necessary  cost  of  doing  business,  they  will  be  developed  and 
implemented  at  industry  expense.  Where  they  are  perceived  as 
adding  additional  cost  or  being  required  as  a  part  of  a 
particular  procurement,  industry  will  probably  expect  their  costs 
to  be  funded,  or  at  least  shared,  by  the  requiring  DoD  component. 

Other  contractual  issues  that  will  require  resolution 
include  how  costs  for  data  preparation,  maintenance  and  access 
should  be  allocated,  how  quality  assurance  and  delivery 
requirements  for  digital  data  can  be  satisfied  and  how 
proprietary  rights  to  data  can  be  protected. 


1.2.3  Integration  Issues.  The  roost  significant  integration 
issue  is  that  of  the  various  data  requirements.  Present 
logistics  standards  and  data  item  descriptions  contain  large 
overlaps  and  gaps,  are  not  oriented  toward  computerized 
production  and  are  often  managed  by  separate  organizations. 
Integration  of  the  data  requirements  of  these  DIDs  into  a  single 
comprehensive  set  of  logistics  data  requirements  would  eliminate 
such  inefficiencies  as  procurement  of  Ground  Support  Equipment 
Recommendation  Data  (GSERD)  and  LSAR  "E"  record  data  at  the  same 
time . 

A  second  integration  issue  is  that  of  activities  that  have 
traditionally  been  established  and  managed  as  separate  entities. 
This  includes  functions  such  as  preparation  of  Provisioning 
Technical  Documentation  (PTD),  identification  of  technical  manual 
requirements,  preparation  of  Illustrated  Parts  Breakdowns  (IPBs) 
or  Repair  parts  and  Special  Tools  Lists  (RPSTLs)  and  the 
instructional  system  development  process.  The  common  elements  of 
these  activities  must  be  integrated  and  incorporated  into  the 
LSAR  development  process. 

Other  integration  issues  that  must  be  addressed  include 
integration  of  design  and  logistics  data  requirements  and 
development  of  the  means  to  relate  design  and  logistics  data. 

1.3  Likely  Payoffs  and  Benefits.  The  integration  and 
automation  of  support  planning  and  acquisition  processes  would 
produce  the  following  benefits:  (1)  improved  readiness  and  lower 
operation  and  support  costs  through  development  of  more  optimum 
support  systems  and  strategies,  (2)  lower  data  acquisition  costs 
through  the  use  of  automated  processes,  integration  of  data 
requirements,  access  to  various  government  data  sources  and 
timely  feedback  of  field  experience  data,  (3)  improved  access  to 
needed  data  by  both  industry  and  DoD  activities,  (4)  improved 
ability  to  quantify  the  impact  of  design  changes  on  support  and 
readiness , 


readiness,  (5)  improved  integration  of  planning  concepts  and 
support  data,  (6)  shorter  flow  times  for  support  system 
development  and  support  resource  acquisition,  and  (7)  lower 
support  item  procurement  costs  due  to  better  utilization  of 
existing  assets  and  improved  requirements  development  for  new 
support  items. 

1.4  Changes  Needed  and  Problems.  The  changes  that  will  be 
required  in  order  to  implement  the  capabilities  discussed  in 
paragraph  1.1  include  the  following: 

a.  The  full  range  of  LSAR  data  and  products  must  be 
automated.  The  present  LSAR  standards  (including  MIL-STD-1 388— 
2A)  do  not  provide  for  full  automation  of  the  LSAR  data  and 
products . 

b.  The  LSAR  data  requirements  and  output  products  must  be 
expanded  to  include  all  of  the  necessary  logistics  data 
requirements  and  to  include  additional  functions.  Additional 
products  that  must  be  provided  for  include,  but  are  not  limited 
to,  Ground  Support  Equipment  Recommendation  Data  ( GSERD) , 
Consolidated  Support  Equipment  List  (CSEL),  training  task  and 
skills  analysis  data,  preliminary  work  unit  code  list,  LSA 
candidate  list  and  Calibration  Measurements  Requirements  Summary 

( CMRS ) .  Additional  functions  that  should  be  provided  for  include 
development  of  technical  manual  requirements  and  tracking  of 
engineering  change  impacts/incorporation  status. 

c.  A  common  set  of  audit  trail  and  configuration  control 
requirements  must  be  established  for  the  LSAR  data.  Presently 
each  major  logistics  data  item  has  its  own  unique  configuration 
control  and  audit  trail  requirements.  These  are  usually  tailored 
to  the  needs  of  the  responsible  DoD  component  or  organization. 
Integration  of  the  logistics  data  requirements  and  products  are 
going  to  require  that  the  configuration  control  and  audit  trail 
requirements  be  integrated  also. 


d.  A  common  data  indexing  structure  must  be  implemented 
for  both  logistics  and  design  data.  Presently,  each  major  type 
of  logistics  data  is  indexed  utilizing  its  own  unique  structure. 
LSAR  data  are  indexed  by  LSA  Control  Number  (LSACN),  provisioning 
data  by  Provisioning  Contract  Control  Number  (PCCN)  and 
Provisioning  List  Item  Sequence  Number  (PLISN),  field  maintenance 
data  by  Work  Unit  Code,  depot  maintenance  data  by  work  order, 
Defense  Logistic  Agency  (DLA)  data  by  Federal  Stock  Class  (FSC) 
or  Manufacturers  Part  Number  (MPN) /Federal  Supplier  Code  for 
Manufacturers  (FSCM)  and  design  data  by  drawing  or  part  number. 
Any  attempt  to  integrate  the  various  logistics  data  requirements 
with  each  other,  or  with  those  of  design  activities,  will  be 
complicated  or  prevented  by  the  lack  of  a  common  data  indexing 
structure . 

e.  Clear  guidelines  must  be  developed  concerning 
ownership,  location,  transition,  access  authorization  and 
responsibility  for  maintenance  of  the  LSAR  data  base.  Presently, 
much  of  the  required  logistics  data  are  incrementally  delivered 
and  incorporated  into  various  DoD  data  systems  or  simply  archived 
in  hard  copy  formats.  Each  of  the  various  requiring  activities 
and  associated  contractor  organizations  maintains  their  own  "data 
base"  with  little  or  no  coordination  between  them.  As  a  result, 
at  any  given  point  in  time,  no  two  of  the  agencies  are  operating 
from  the  same  data.  In  addition,  once  the  system  has  been 
fielded,  there  is  no  single  Service  agency  responsible  for 
delivery,  acceptance,  maintenance  and  preservation  of  the 
system's  LSAR  data  base. 

f.  A  DoD-wide  capability  to  provide  meaningful  feedback  of 
field  experience  data  to  both  industry  and  DoD  components  must  be 
developed.  This  capability  is  necessary  in  order  to  provide 
comparison  and  lessons  learned  data  to  weapon  system  design  and 
modification  efforts,  provide  for  efficient  weapon  system  support 
management  and  to  provide  accurate  management  visibility  of 
weapon  system  readiness. 
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The  problems  that  will  be  encountered  in  implementing  the 
changes  discussed  above  include  the  following: 

a.  Integration  of  the  various  logistics  data  requirements 
and  products  into  the  LSAR  will  require  changes  to  the  way  that 
both  industry  and  DoD  components  have  traditionally  performed 
their  functions.  The  impact  of  this  change  can  probably  be 
minimized  by  producing  the  various  deliverable  products  in  their 
traditional  formats,  but  the  effect  will  still  be  significant,  as 
it  will  require  all  of  the  various  functional  organizations  to 
become  a  part  of  the  LSAR  development  and  update  process.  Given 
the  tradition,  within  both  the  Services  and  industry  of  assigning 
LSAR  activities  to  a  single  functional  organization,  considerable 
resistance  to  integration  of  the  LSAR  data  requirements  can  be 
anticipated . 

b.  Appropriate  tailoring  of  LSAR  requirement  has  and  will 
continue  to  be  a  problem.  As  a  result  of  the  LSAR  data  being 
encompassed  by  a  single  standard  and  a  general  lack  of  detailed 
logistics  knowledge  by  procurement  personnel,  there  is  a  tendency 
to  make  LSAR  requirements  all  encompassing  rather  than  tailored 
appropriately  to  each  procurement.  The  decision  to  create 
separate  DIDs  for  each  MIL-STD-1 388-2A  output  summary  is  a  step 
in  the  right  direction,  but  more  will  have  to  be  done. 
Consolidation  and  integration  of  the  LSAR  requirements  will 
magnify  the  cost  and  schedule  impact  of  imposing  untailored 
requirements . 

c.  Given  the  current  pressure  on  the  budgeting  process, 
the  traditional  difficulty  of  funding  support  improvements  and 
the  fact  that  many  of  the  benefits  will  not  accrue  to  the 
developing  organizations,  funding  for  development  and 
implementation  of  the  changes  discussed  above  require  a  high 
level  DoD  commitment  and  development  of  firm  policy  guidelines. 


d.  The  difficulty  of  changing  both  industry  and  DoD  design 
data  indexing  structures  to  accommodate  needed  changes  should  not 
be  under-estimated.  The  standards  and  systems  utilized  to 
prepare,  release  and  control  design  definition  data  have  been 
built  up  over  the  course  of  many  years,  and  changing  them  will 
not  be  an  easy  matter.  On  a  broader  scale,  what  is  really  being 
requested  is  a  reorientation  of  design  activities  to  give  greater 
consideration  to  support  requirements. 

e.  Resistance  on  the  part  of  industry  to  radical  and/or 
continual  change  of  the  LSAR  requirements  can  be  expected.  Many 
contractors  made  substantial  investments  in  computerized  LSAR 
systems  to  respond  to  the  original  release  of  MIL-STD-1 388 . 

These  investments  have,  to  a  large  degree,  been  nullified  by  the 
development  and  release  of  MIL-STD-1 388-2A .  The  reason  for  this 
is  that  the  revised  standard  made  significant  changes  to  the  LSAR 
data  requirements  and  structure  and  most  industry  systems  could 
not  be  modified  to  accommodate  them.  In  order  to  develop  and 
implement  industry  LSAR  systems  that  are  integrated  with  those  of 
the  design  and  manufacturing  process,  flexibility  and  growth 
provisions  for  both  data  and  relational  considerations  will  have 
to  be  planned  into  the  LSAR  system  requirements.  Continual 
additions  and  changes  to  the  LSAR  data  requirements  will  result 
in  LSAR  systems  being  implemented  on  a  "band  aid"  basis  to  each 
project.  This  type  of  implementation  generally  results  in  a 
less-than-optimum  data  system  that  has  few  interfaces  with  other 
industry  systems.  In  order  for  industry  to  develop  truly 
integrated  LSAR  systems,  and  DoD  components  to  enjoy  the  benefits 
that  those  systems  could  provide,  a  high  degree  of  stability  and 
predictability  must  be  introduced  into  the  LSAR  data  and  data 
system  requirements. 
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2. 


IDENTIFICATION  OF  CANDIDATE  FUNCTIONS 


2.1  Candidates  for  Automation.  As  discussed  in  paragraph  1.1, 
candidates  for  automation  include  the  support  system  development 
process,  LSAR  development  and  reporting  process,  various  support 
development  activities  (including  instructional  system 
development,  facilities  design  criteria  preparation,  support 
equipment  specification  development  and  transportability 
analysis),  and  Service  access  to  LSAR  data. 

2.2  Candidates  for  Standardization.  Candidates  for 
standardization  include  LSAR  data  requirements  and  delivery 
formats.  In  order  to  implement  integrated  LSAR  data  systems, 
some  additional  standardization  of  the  LSAR  data  requirements  and 
delivery  requirements  must  be  made.  In  the  past,  LSAR  data 
requirements  have  varied  between  projects  and  Services  so  greatly 
that  it  was  virtually  impossible  to  develop  a  single  system  for 
use  on  all  procurements.  An  important  step  toward  standardizing 
the  LSAR  requirements  was  made  with  the  publication  of  MIL-STD- 

1 388-2A .  This,  however,  does  not  mean  that  all  of  the  problems 
have  been  solved.  Important  questions  still  remain  concerning 
standardized  tri-Service  Provisioning  Technical  Data  (PTD) 
formats,  implementation  of  project  and  organization  peculiar  LSAR 
systems  and  the  acceptability  of  LSAR  outputs  as  hard  copy 
delivery  formats.  As  logistics  systems  and  LSAR  development 
activities  make  increasing  use  of  on-line  data  systems  and 
interactive  processes,  it  will  become  necessary  to  develop  a 
standardized  method  for  DoD  components  to  query  industry  systems. 
Without  some  standard  method,  it  would  be  necessary  for  Service 
personnel  to  be  familiar  with  the  structure  and  operation  of  each 
industry  system  that  they  need  to  utilize. 

2.3  Candidates  for  Integration.  The  primary  candidates  for 
integration  are  the  data  requirements  of  the  various  standards 
and  DIDs.  Without  this  integration,  little  meaningful  progress 


can  be  made  toward  development  and  implementation  of  integrated 
LSAR  data  systems,  computer-aided  processes  for  support 
development  activities  and  on-line  delivery  of  logistics  planning 
data . 

3.  ANTICIPATED  RECOMMENDATIONS 
3. 1  Funding  Issues. 

o  Cost  of  continually  changing  industry  systems. 


Incentive  Issues 

Contracting  Issues 

Specif ication  and  Standards  Issues 


Technological  Changes 


Move  from  batch  language  software  to  neutral  data 
format . 

Common  set  of  on-line  queries. 


System  Characteristics 
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1.  General 
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Table  2-19. 


IDRF  AO,  SUMMARY 


D00 

AO  Provide  Computer  Aided  Logistics  Support 

The  purpose  is  to  describe  the  framework  of  a  Computer  Aided  Logistics 
Support  (CALS)  system  that  would  allow  DOD  to  make  full  use  of  contractor 
generated  digital  data.  The  focus  as  described  by  the  CALS  architecture 
subgroup,  is  the  automation,  standardization,  and  integration  of  the 
existing  logistics  system. 


Existing  Log  System  -  An  all  encompassing  term  denoting  the  present  way  of 
handling  the  planning,  and  data  related  to  the  design  and  acquisition 
of  support  resources,  primarily  hard  copy,  manually. 

Technology  -  Technical  issues  related  to  computerizing  all  aspects  of  design 
influence  and  logistic  support. 

Data  Requirements  -  The  data  and/or  information  required  for  design 

influence  and  the  design,  acquisition  and  preparation  of  support 
resources. 


DOD  Policy,  Budget,  Reqmts  -  Constraints  placed  on  the  development  and 
implementation  of  CALS  for  which  the  Government  is  responsible. 

CALS  Arch  Subgroup  -  The  IDA  CALS  adhoc  subgroup  assigned  to  address 
implementation  architecture  issues. 

CALS  System  -  Computer  Aided  Logistic  Support  envisioned  as  a  system  concept 
beginning  at  the  prime  equipment  design  phase  and  ending  at  its 
obsolescence. 


CALS  FUNCTIONAL  DESCRIPTIONS 
DoD  FUNCTIONS: 

2,  IDEF  Al,  CALS  for  Support  Acquisition  and  Management 
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Figure  2-29.  IDEF  Al,  PROVIDE  SUPPORT  ACQUISITION  MANAGEMENT,  DOD 


Table  2-20.  IDS?  Al,  SUMMARY 


A1  Provide  Support  Acquisition  and  Management 


Glossary 

System  Specs  -  The  top  level  documents  which  define  the  system's 
requi rements. 

Hardware  Software  Engrg  Changes  -  Changes  to  the  design  of  the  hardware  or 
software  resulting  from  test,  reevaluation,  or  other  requirements. 

Config.  Mgr.  -  The  individual  responsible  to  manage  and  control  the 

hardware/software  configuration  and  its  documentation  relationship. 

Contractor  -  The  organization  responsible  for  performing  to  the  contract. 

Engineering/Operational  Requirements  -  The  specified  performance  require¬ 
ments  and  operational  scenarios  including  maintenance  scenarios  from 
which  to  tailor  the  support  resource  acquisition. 

Change  Control  Boards  -  A  committee  of  persons  from  affected  Departments  who 
review  and  judge  the  need  for  design  changes;  considering:  cost  and 
schedule  impact,  change  necessity,  effectivity,  configuration 
concerns,  design  and  performance  Impact,  and  other  matters. 

Config.  Audits  - 

Funding/Contract  -  The  money  and  contract  made  available  to  acquire  the 
support  resources. 

Accurate  Config.  Data  -  Configuration  management  data  which  accurately 
portrays  the  updated  configuration  of  a  material  item. 

Support  Requirements  -  The  Government  (user)  approved  maintenance  planning. 

Support  Resource  -  An  item  or  person  required  to  perform  maintenance  as 
provided  from  the  maintenance  planning  process. 

Ready  the  Systems  -  On  date  at  which  all  maintenance  resources  are  in  place 
and  the  user  organization  self  sufficient  for  maintenance. 

Logistics  Acquisition  Manager  -  The  person  responsible  to  obtain  the 
approval  logistic  resources  for  the  Government. 

LSAR  -  Logistic  Support  Analysis  Record  documenting  the  results  of  analyses 
from  which  the  maintenance  concept  and  support  resource  requirements 
are  derived. 
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'able  2-21.  TH^tt  Alla,  SUMMARY 


Alin  Perform  Configuration  Management 


Glossary 

System  Specs  -  The  top  level  documents  which  define  the  system's 
requi rements. 

Contractor  -  The  organization  responsible  for  performing  to  the  contract. 

Hardware  Software  Engineering  Changes  -  Changes  to  the  design  of  the 
hardware  or  software  resulting  from  test,  reevaluation,  or  other 
requi rements. 

Base  Line  Configuration  -  The  configuration  of  the  hardware  and  software 
established  and  documented  at  a  particular  period  of  time. 

Engineering/Operational  Requirements  -  The  specified  performance  require¬ 
ments  and  operational  scenarios  including  maintenance  scenarios  from 
which  to  tailor  the  support  resource  acquisition. 

Support  Changes  -  Changes  in  support  planning  or  support  resources  tailored 
to  equipment  changes. 

Change  Control  Boards  -  A  committee  of  persons  from  affected  Departments  who 
review  and  judge  the  need  for  design  changes;  considering:  cost  and 
schedule  Impact,  change  necessity,  effectivity,  configuration 
concerns,  design  and  performance  impact,  and  other  matters. 

Configuration  Manager  -  The  individual  responsible  to  manage  and  control  the 
hardware/ software  configuration  and  its  documentation  relationship. 

Compatible  Logistics  Support  -  Logistic  support  adjusted  to  address  the 
specified  configuration  of  the  system/equipment  being  supported. 

Configuration  Audits  - 

Accurate  Configuration  Data  -  Configuration  management  data  which  accurately 
portrays  the  updated  configuration  of  a  material  item. 


7i^ure  2-32.  IDEF  A12n,  PERFORM  SYSTEM  LIFE  CYCLE  MANAGEMENT,  DOD 


^able  2-22 .  IEEF  A12n,  SUMMARY 


A12n  Perform  System  Life  Cycle  Management 


G1  ossary 

Support  Requirements  -  The  Government  (user)  approved  maintenance  planning. 

ILS  Plans  -  Documents  which  define  the  approach  for  Integrated  Logistics 
Support  (ILS)  on  a  program;  including  schedule,  milestones, 
activities,  responsibilities,  interfaces  with  other  portions  of  the 
program,  etc. 

Contractor  -  The  organization  responsible  for  performing  to  the  contract. 

Budget/Regulations  -  Constraints  placed  on  the  acquisition  manager  in  the 
acquisition  and  maintenance  of  support  resources. 

Support  Structure  -  The  maintenance  concept  upon  which  the  support  planning 
is  based.  It  determines  the  maintenance  levels  and  resources  at  each 
level . 

Acquisition  Managers,  Logistics  Manager,  Program  Management  -  The  manager 
responsible  for  support  resource  acquisition,  support  planning  and 
support  requirements  development. 

Ready  the  Systems  -  On  date  at  which  all  maintenance  resources  are  in  place 
and  the  user  organization  self  sufficient  for  maintenance. 


IDEF  A 1  DESCRIPTION 

CALS  FOR  SUPPORT  ACQUISITION  AND  MANAGEMENT 


CURRENT  STATUS 

Primarily  hard  copy 
Inputs 

-  Controls 
Outputs 

TARGET  SYSTEM  CHARACTERISTICS 

Automated  (soft  copy) 

Inputs 

Outputs 

Controls 

Automated  resource  management 


BENEFITS 

More  efficient  and  cost-effective  management  of 
resources 

Expedites  planning,  acquisition,  and  management  process 

More  cost-effective  utilization  of  corporate  experience 
resident  in  data  base 

Faster  adjustment  of  acquisition  strategies  in  response 
to  changing  requirements 

Immediate  availability  of  configuration  change  control 
data  enhances  data  system  currency 

Continuously  updated  configuration  status  accounting 
information 


Rapid  response  of  logistics  support  system  to 
configuration  changes 


PROBLEMS 


Compatibility  of  contractor  and  Government  data  systems 

Availability  and  compatibility  of  contractor  data 

Proliferation  of  high  capacity  PCs  promotes  creation 
and  utilization  of  individualized  unique  systems 
exacerbating  the  centralized  control  and  coordination 
problem 


IMPLEMENTATION  APPROACH 

Standardize  specification  imposed  by  Services  on 
contractors  for  automation  of  deliverable  technical 
data 

Services  established  own  automation  capabilities  to 
utilize  and  mesh  with  contractors  automation  systems 

Establish  DOD  oversight  of  Service  activities  in  these 
areas  and  provide  specific  DOD  direction 

Provide  adequate  funding 


IMPLEMENTATION  COST 

The  approach  is  too  MACRO  at  this  point  for  any  kind  of 
useful  cost  estimate. 


IDEF  A 1  CONCEPT  PAPER 


CALS  FOR  SUPPORT  ACQUISITION  AND  MANAGEMENT 

1.  FOCUS  OF  CALS  IMPLEMENTATION 

1.1  Overview.  The  concept  of  using  Computer-Aided  Logistics 
Support  (CALS)  to  improve  System  Support  Acquisition  and 
Management  requires: 

a.  Positive  management  actions  to  integrate  all  logistics 
elements  within  a  program  in  order  to  optimize  the  availability 
of  resources  and  to  minimize  support  costs, 

b.  A  systematic  management  approach  to  the  early 
integration  of  support  criteria  into  design  activities,  and 

c.  A  credible  technical  basis  for  developing  and/or 
improving  Life  Cycle  Cost  estimates  within  the  performance  and 
availability  requirements  of  the  program. 

The  advancements  in  computer  and  communication  technology 
provide  vast  opportunities  for  logistics  managers  to  introduce 
new  methodologies  into  logistics  management  techniques.  The 
trend  toward  distributive  processing--the  use  of  small, 
specialized  computers  tied  together  to  reduce  or  eliminate  the 
need  for  large  data  bases--will  result  in  an  increased 
requirement  for  high-speed  communications  circuits  within  and 
between  the  various  levels  of  logistics  support.  The  trend 
toward  higher  data  exchange  volumes  can  be  expected  to  continue 
to  increase  as  Government  computer  operations  move  from  large- 
scale  computers  and  batch  processing  to  smaller  computers  and  on 
line  distributive  processing. 

1.2  Implementation  Considerations.  Considerations  of  CALS  in 
System  Support  Acquisition  and  Life  Cycle  Management  should 
include  the  following: 


a.  Complete  and  up-to-date  information  essential  to  life- 
cycle  support  of  a  system/program, 

b.  Access  to  this  information  for  concerned  parties  from 
various  geographical  locations,  and 

c.  Data  base  access  and  control  of  data  base  integrity. 

The  configuration  of  a  logistics  support  information 
processing  network  with  a  series  of  '’hub*'  computers  and  satellite 
terminals  laid  out  in  pyramid  fashion  would  provide  vertical  as 
well  as  horizontal  access  to  all  of  the  data.  At  the  lowest 
level,  each  of  the  logistics  element  managers  would  be  a  "hub" 
for  information  relating  to  a  particular  element  (e.g.,  spares, 
technical  data,  training,  etc.)  for  a  specific  program.  At  the 
next  higher  level,  each  logistics  program  manager  would  be  a 
"hub"  for  information  on  all  logistics  elements,  as  well  as  on 
other  related  functions  (e.g.,  configuration  management, 
engineering,  data  management,  etc.)  for  a  specific  program.  The 
next  higher  level  would  have  a  logistics  systems  manager  who 
would  be  a  "hub"  for  all  logistics  program  managers.  Other 
levels  of  management  could  be  interspersed  in  order  to  provide  a 
greater  degree  of  control;  however,  functions  and  capabilities 
would  remain  essentially  the  same.  Each  "hub"  would  have  access 
to  various  data  bases,  with  the  "hub"  manager  being  able  to 
change  the  information  in  a  particular  data  base  as  required  by 
its  particular  level.  The  manager  would  have  query  capability 
only  for  those  data  bases  provided  by  lateral  and  subordinate 
activities;  however,  he  would  be  able  to  access,  input,  and 
revise  those  data  bases  which  provide  information  to  lateral  and 
superior  activities. 

1.3  Payoffs  and  Benefits.  There  are  several  immediate 
benefits  which  can  be  derived  from  having  complete  and  up-to-date 
information  on  all  aspects  of  a  system's  support  structure  in  a 
central  location  which  is  accessible  to  all  parties  with 
legitimate  needs.  These  benefits  are  listed  below. 


a.  Expedites  access  to  maintenance,  spares,  and 
configuration  information. 

b.  Provides  centralized  control  of  system  diagnostics, 
technical  orders,  and  hardware/software  changes. 

c.  Provides  users  interactive  training  programs. 

d.  Provides  a  ready  source  of  baseline  equipment  from  the 
numerous  computers  in  current  use. 

The  prioritized  needs  of  the  total  set  of  on-site  and  remote 
users  will  determine  how  intelligent  and  how  powerful  the  remote 
terminals  must  be  in  relation  to  the  console  terminals  co-located 
with  the  host  facility.  Access  to  the  central  facility  involves 
both  retrieving/refreshing  information  resident  in  the  data  banks 
and  using  the  central  processing  unit  in  the  large  host  computer. 

1.4  Changes  Weeded  and  Anticipated  Problems.  Of  the  changes 
needed  and  problems  anticipated  in  establishing  a  logistics 
support  information  processing  network  for  logistics  management 
support,  user  priority  is  one  of  the  most  important 
considerations.  The  question  of  user  priority  must  be  addressed 
in  defining  the  hierarchical  structure  of  information  processing. 

The  necessity  for  a  common  communications  interface  and 
command  language  is  obvious  and  should  be  addressed  early  in  the 
network  planning  process.  A  properly  researched  statement  of 
requirements  and  adoption  of  a  particular  communications  protocol 
can  have  a  synergistic  effect  upon  a  distributed  data  processing 
(DDP)  network,  thereby  eliminating  protocol  conversion  and 
retrofit.  Such  adoption  may  narrow  the  field  of  vendors  but  also 
may  have  the  positive  impact  of  preventing  computer  manufacturers 
and  network  users  from  committing  themselves  to  unique  and 
incompatible  protocols. 

The  Department  of  Defense  is  moving  toward  standardization 
with  MIL -STD- 1 777 ,  Internet  Protocol  Standard,  and  MIL-STD-1778 , 
Transmission  Control  Protocol  Standard,  which  were  adopted  by  the 
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Air  Force  on  1  March  1983.  To  further  direct  standardization 
efforts,  the  Department  of  Defense  has  entered  into  a  cooperative 
venture  with  the  National  Bureau  of  Standards. 

2.  CANDIDATE  FUNCTIONS  FOR  CALS 

There  is  no  single  logistics  element  or  related  function 
which  would  not  be  a  candidate  for  automation,  standardization, 
and  integration  into  a  hierarchical  CALS  information  processing 
network . 

2.1  Technical  and  Maintenance  Data.  One  interesting  CALS 
application  will  be  to  place  technical  and  maintenance  manuals  on 
videodisc/videotape.  On  a  videodisc,  for  instance,  10  seconds  of 
audio  could  accompany  one  frame  of  video,  making  possible  a 
talking  maintenance  manual  providing  27,000  full-color,  still- 
frame  pictures  and  75  hours  of  audio  commentary  on  one  disc.  A 
relatively  cheap  microcomputer  can  control  the  videodisc  player 
with  an  inexpensive,  commercially  available  interface.  The 
ability  of  this  system  to  access  frames  randomly  and  run  still, 
slow,  or  full  motion  is  well  suited  to  locally  programmable 
training,  briefing,  and  maintenance  applications.  The  video  and 
audio  presentations  can  then  be  saved  on  a  videotape  for  further 
distribution.  Spare  parts  listings  and  ordering  information 
currently  on  microfiche  can  be  transferred  to  videodisc,  allowing 
use  of  the  videodisc  hardware  for  many  purposes. 

2.2  Support  Acquisition  Data.  Support  acquisition  using  this 
information  network  will  benefit  from  more  accurately  predicting 
the  requirements  for  spares  and  repair  parts.  It  will  permit 
better  production  planning  and  justify  setting  aside  industrial 
facilities  to  make  spares  for  systems.  This,  in  turn,  will 
permit  the  Government  to  get  better  prices  and  shorter  leadtimes 
from  industry  when  it  can  be  shown  that  paying  inventory  carrying 
costs  to  shorten  leadtime  and  letting  multiyear  contracts  to 
reduce  the  unit  price  can  be  justified  by  the  utilization  rate. 


Information  on  the  utilization  rate  will  be  readily  available  for 
any  system/equipment,  along  with  other  information  such  as  the 
technical  specification,  cost  and  schedule  information,  and  the 
results  of  level  of  repair  (LOR)  and  logistics  support  analyses. 

2.3  Configuration  Management  Data.  In  the  area  of 
configuration  management,  this  information  network  can  be  used  to 
provide  the  configuration  status  of  each  piece  of  equipment  by 
serial  number,  type,  and  model.  All  reference  designators,  such 
as  drawing  number,  revision,  and  modification  identification, 
also  will  be  entered.  Then,  as  a  modification  or  retrofit  is 
made  to  an  equipment,  the  information  will  be  entered  into  the 
system  identifying  the  type  of  modification.  Anyone  with  access 
to  the  system  will  then  be  able  to  determine  which  equipment  has 
what  modifications.  This  will  ensure  system  compatibility  when  a 
piece  of  equipment  is  replaced,  permit  accurate  configuration 
status  accounting,  and  allow  managers  to  make  better  utilization 
of  limited  resources. 

2.4  Resource  Planning  Data.  Resource  planning  will  be  easier 
and  faster  using  this  information  network,  no  matter  what  stage 
of  the  acquisition  cycle  is  involved.  It  will  not  make  much 
difference  whether  it  is  to  provide  for  site  activation,  system 
maintenance,  round-the-clock  operation,  or  phasing  out  an 
equipment;  having  all  of  the  related  information  available  when 
and  where  it  is  needed  will  be  a  tremendous  improvement  over  the 
current  paperwork  and  manpower-heavy  manual  systems.  Managers 
will  seek  information  not  by  word  of  mouth  but  rather  through 
pictures  (computer  graphics).  Computer  graphics  systems  will 
allow  a  machine  to  do  much  of  the  data  aggregation,  synthesis, 
and  presentation  which  is  currently  being  performed  manually. 

Some  of  the  problems  of  information  overload,  perishable 
data,  and  cost  of  production  of  presentations  may  be  mitigated  by 
the  current  technology  of  computer  graphics.  The  two  most  basic 
benefits  of  computer  graphics  will  be  in  saving  the  manager's 


time  and  in  helping  managers  make  better  decisions.  Computer 
graphics  can  save  the  manager's  time  by  simplifying  the 
interpretation  of  data  and  by  facilitating  the  communications  of 
complex  findings.  Computer  graphics  help  managers  make  better 
decisions  by  allowing  them  to:  (1)  scan  and  digest  more 
information,  (2)  detect  trends  or  deviations  more  readily,  and 
(3)  rapidly  generate  many  different  presentations. 

3.  ANTICIPATED  RECOMMENDATIONS 

3.1  Funding  Issues.  Successful  Government  ILS  planning  durin 
all  phases  of  the  equipment  life  cycle  requires  management 
attention  to  the  interface  between  the  support  element  needs  and 
defense  budgeting  and  financing  procedures.  Typical  budgeting 
and  financing  activities  will  include: 

a.  Early  determination  of  logistics  support  funding 
requirements  which,  together  with  experience  factors  obtained 
from  similar  equipment  programs,  permit  accurate  forecasting  of 
Life  Cycle  Costs; 

b.  Accurate  updating  of  forecasts  for  timely  fiscal 
planning  and  apportionment  of  required  research  and  development, 
investment  and  operating  funds;  and 

c.  Accurate  accounting  of  funds  expenditures  using  work 
breakdown  structure  and  measurement  criteria  to  ensure  proper 
funds  utilization  and  redistribution. 

There  are  several  alternatives  to  consider  when  addressing 
funding  for  developing  the  concept  of  using  Computer-Aided 
Logistics  Support  (CALS)  to  improve  System  Support  Acquisition 
and  Management.  They  range  from  total  Government-sponsored 
development  of  potential  CALS  applications  to  providing 
incentives  to  industry  to  develop  CALS  techniques  and  procedures 
A  good  starting  point  might  be  for  the  Government  to  provide 
matching  funds  to  industry  to  encourage  development  of  fully 
automated  procedures.  However  it  is  done, the  first  phase 


should  include  a  formal  feasibility  study  to  determine  the 
constraints  and  limitations  that  CALS  would  operate  within. 

3.2  Incentive  Issues.  In  order  to  accelerate  the  development 
of  automated  Support  Acquisition  and  Management  processes,  the 
Government  must  provide  the  necessary  incentives  to  industry. 
Incentive  issues  should  address  funding  for  all  support  studies, 
exploratory  development  of  support  items  requiring  state-of-the- 
art  advancement,  and  include  the  proposed  allocation  of  concept 
formulation  fund  requirements. 

3-3  Contracting  Issues.  The  major  contracting  issues  to  be 
addressed  will  result  from  the  use  of  obligatory,  standard 
computerized  Support  Acquisition  and  Management  techniques  which 
will  impact  contractual  regulations.  The  Government  should  be 
able  to  gain  the  necessary  competitive  leverage  with  the 
potential  contracting  sources  by  invoking  a  requirement  for 
automated  Support  Acquisition  and  Management  procedures  in 
certain  specific  Requests  for  Proposal  ( RFP ) .  Although  there  are 
other  methods,  this  would  probably  be  the  most  cost-effective  way 
to  provide  the  necessary  incentive  for  contractors  to  adopt  CALS 
techniques.  It  should  also  be  the  most  direct  and  timely 
alternative  for  the  Government  to  employ  in  order  to  obtain  CALS 
to  improve  System  Support  Acquisition  and  Management  techniques. 

3 Specification  and  Standards  I33ue3.  Standardization  and 
specification  issues  are  critical  items  which  must  be  addressed 
at  the  outset  in  order  to  prevent  a  proliferation  of  independent, 
stand  alone  models,  a  condition  which  would  inhibit,  if  not 
prevent,  interoperability  among  potential  users.  One  way  to 
ensure  compatibility  would  be  to  retain  the  manual  methods  of 
providing  for  System  Support  Acquisition  and  Management  while 
transitioning  to  CALS.  This  will  permit  existing  specification 


and  standards  to  be  modified/adjusted  concurrently  with  the 
preliminary  development  of  automated  programs.  This  also  will 
allow  the  Government  to  obtain  the  maximum  utilization  out  of  the 
numerous  "personal  computers"  already  in  use,  while  transitioning 
into  the  final  networking  of  computers. 

3.5  Technological  Changes.  The  projected  technological 
advances  in  computer  technology,  data  management  and  exchange 
techniques,  and  communications  methods  should  encourage  the  rapid 
introduction  of  an  automated  concept  for  Government  and  industry 
alike  within  the  very  near  future. 

3.6  System  Characteristics.  In  defining  system  character¬ 
istics,  areas  such  as  data  security,  data  integrity,  and 
proprietary  data  rights  must  all  be  given  high  priority.  The 
need  for  access  to  the  information  contained  on  the  system  by 
concerned  parties  from  various  geographical  locations  must  be 
weighed  against  the  need  to  control  access  to  the  system.  The 
requirement  for  constant  updates  and/or  reviews  of  the  data  base 
must  be  balanced  by  the  concern  for  data  loss  and  unauthorized 
manipulation.  Finally,  the  need  to  respect  proprietary  data 
rights  and  techniques  must  not  interfere  with  the  Government’s 
right  to  obtain  the  basic  data  necessary  to  develop/expand  CALS. 

3.7  Policy  Issues.  Governmental  invocation  of  contractual 
obligation  by  industry  to  comply  with  approved  standards  for 
system  development  is  now  an  accepted  provision  of  DoD  policy. 
Therefore,  requiring  industry  to  implement  standard  computerized 
Support  Acquisition  and  Management  techniques  during  systems 
development  should  not  require  any  significant  modification  to 
the  DoD  systems  acquisition  policies. 


4. 


CHOICE  OF  CANDIDATES  JUSTIFICATION 


4.1  High  Payoff.  The  Support  Acquisition  and  Management 
candidates  for  automation  will  provide  the  opportunity  for 
substantial  cost  benefits  in  terms  of 

o  Paper  reduction, 

o  Improved  data  accuracy,  and 

o  Improved  data  availability. 

Cost  benefits  in  paper  reduction  alone  will  justify  the 

automation  of  Support  Acquisition  and  Management  of  systems.  In 
addition  to  the  savings  in  reduction/elimination  of  reports, 
plans,  etc.,  there  is  the  potential  of  tremendous  savings  in  the 
filing  and  storage  of  paper  documents. 

4.2  Feasibility.  The  concept  of  fully  automated  techniques 
for  Support  Acquisition  and  Management  procedures  is  well  within 
the  realm  of  functional  feasibility,  given  the  present  state-of- 
the-art  electronic  data  processing  technologies.  The 
proliferation  of  decentralized,  nonstandard,  and  relatively 
inexpensive  computer  aids  will  quickly  lead  to  development  and 
implementation  of  automated  Support  Acquisition  and  Management 
procedures  by  industry  as  well  as  by  Government.  The  Government 
must  get  the  jump  on  this  rapidly  expanding  phenomenon  to  take 
full  advantage  of  its  vast  potential  for  improved  product  quality 
and  decreased  acquisition  leadtimes  and  associated  costs. 


CALS  FUNCTIONAL  DESCRIPTIONS 
DoD  FUNCTIONS: 

3.  IDEF  A2,  CALS  for  Training 
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Table  2-23.  IDEF  A 2,  SUMMARY,  DOD  (sheet  1  of  2) 


A2  Provide  Training 

Three  activities  are  used  to  describe  the  framework  for  training.  The 
first  activity  is  the  definition  and  acquisition  of  training  equipment. 
Training  equipment  is  presently  defined  by  individuals  knowledgeable  in  the 
methodologies  of  training  for  the  system  in  question,  and  in  the  results 
required.  They  would  develop  a  plan,  determining  hardware,  software,  and 
procedures;  issue  purchase  requisitions,  specification  and  design  require¬ 
ments;  and  make  the  appropriate  arrangements  to  acquire  all  training 
materials. 

The  next  activity  is  the  development  of  courses.  A  System's  training 
course  is  now  planned  and  written  after  the  design  is  completed,  and  usually 
after  the  hardware  is  built.  Actual  hardware  is  used  to  help  design  the 
course  by  running  it  through  its  paces  and  introducing  faults  and  simulated 
situations.  Courses  are  now  developed  for  either  computer-based  training, 
human  interaction,  or  simulation  techniques  using  actual  hardware. 

The  last  activity  is  the  actual  conducting  of  training.  Computer- 
based  instruction,  equipment  simulation,  and  classroom  and  field  training  on 
actual  equipment  are  all  presently  used. 

Innovations  which  will  affect  training  will  occur  in  computer,  video 
and  training  technologies.  Computer- related  advancements  which  will  impact 
training  include:  improved  user  interfaces,  cheap  memory,  multi-tasking 
machines,  powerful  handhelds,  and  reasonably  costed  3-D  color  graphics 
systems. 

Training  technologies  will  advance  to  take  advantage  of  delivery  media 
improvements.  Artificial  intelligence  (AI)  concepts  will  be  directly  or 
indirectly  applied  to  training.  That  is,  where  feasible,  we  will  use  expert 
training  systems  to  provide  instruction  and  assistance  to  operators  and 
maintenance  personnel. 

G1  ossary 

Cost,  Schedule,  Requirements  -  Cost  and  Schedule  restrictions  are  provided 
by  the  contract  Statement  of  Work.  On-the-job  (OJT)  training  for 
persons  not  familiar  with  the  equipment  could  allow  performance  of  a 
task  by  using  built-in  computer  aids.  Defined  by  the  contact 
Statement  of  Work  as  to  the  type  of  training  required  on  the  program. 
It  could  be  formal,  classroom  training,  on-the-job  (OJT)  training,  or 
other  types. 

Technical  Specification  -  That  document  provided  as  part  of  the  contract 

which  defines  the  operational,  design  and  performance  requirements  of 
the  system. 

Maintenance  Plan  -  Equipment  Specification  and/or  Maintenance  Scenario 
Analyses  at  a  higher  level. 

Instruction  System  -  Maintenance  training,  operator  training,  and  general 
basic  training  as  defined  by  design  requirements. 


Table  2-23.  IDTP  A2,  SUMMARY,  DOD  (sheet  2  of  2) 


A2  Glossary  (Con't) 


Design  Description  -  Results  of  the  design  program;  including  drawings, 
analysis,  schematics,  test  results. 

Order  -  The  process  and  data  used  to  order  material  and  services. 

Training  Material  -  Data  used  to  conduct  the  training  other  than  the 
courseware  (description  of  trainers,  mock-up,  etc). 

Training  Aids  Requirements  -  The  use  of  the  training  devices  and  how  to 
integrate  them  into  the  overall  training  program. 

LSA  data  -  Logistics  Support  Analysis  data. 

Technical  Manuals  -  As  provided  by  Reliability  and  Maintainability  design 
analysis. 

Develop  Material  Testing  -  The  material  used  to  evaluate  the  student's 
performance  and  the  extent  of  learning;  also  the  material  used  to 
evaluate  the  course  content  and  presentation. 

Courseware,  Guides,  Procedures  -  Computer-generated  design  tools  and 
outlines  generated  by  the  design  process. 

Training  Plans  and  Objectives  -  The  achievement  of  built-in-training  which 
provides  for  on-site  field  training  for  equipment  use  and  maintenance 

Test  Results  -  The  results  of  testing  the  student  in  the  course  material. 

Evaluation  Material  -  The  results  of  the  students  evaluation  of  the  course, 
including  recommendations  for  changes  and  improvement. 


TRAINING  PLANS  *  OBJECTIVES 

COST,  SCHEDULE.  RED ’UTS  (FORMAL.  OJT 
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CALS  FUNCTIONAL  DESCRIPTIONS 
DoD  FUNCTIONS: 

4.  IDEF  A3,  CALS  for  Maintenance 
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A3  Perform  Maintenance 


Glossary 

Operational  Requirements  -  Planned  utilization  of  the  system  being 
supported. 

Trends  -  Feedback  from  failure  analyses  to  determine  patterns  of  failure. 

Inspection  &  Overhaul  Requirements  -  Planned  cycles  of  maintenance  and 
activities  therein. 


Operational  Failures  -  The  failure  of  an  item  to  meet  its  intended 
operati onal  requi rement/functi on. 

Schedule/Order  -  Written  instruction  and  authority  to  perform  a  maintenance 
task  including  the  time  phasing. 

Job  Order  -  Detailed  work  statement  with  which  to  execute  the  maintenance 
acti on. 

Resource  &  Equipment  Status  -  Inspection  report  defining  the  items 
serviceable  status  or  repair  requirements. 

Required  Repairs  -  Repairs  needed  to  return  an  item  of  material  to 
operati onal/serviceable  condition. 


Design  Description  -  Design  information  such  as  drawings  or  performance 
specification. 

Supply  Demand  -  Requisition  for  replacement  items. 

Repair  or  Cannibalize  -  Decision  to  fix  an  unserviceable  item  or  use  a 
serviceable  part  from  another  larger  component  or  end  item  as  a 
substitute  for  the  unserviceable  part. 

Status  -  Reported  condition. 


BIT  Ind  -  Built-In-Test  indication. 

T.O.  Procedures  -  Maintenance  procedures  prescribed  in  a  technical  order. 

Engineering  Data  -  Data  and  analysis  developed  during  the  design  and  test 
phases  of  the  program. 

Maintenance  Action  Data  -  Report  delineating  the  maintenance  action, 
resources  required,  task  times  etc,  utilized  to  effect  a  repair. 

Policy  &  Data  System  Design  -  Maintenance  Policy  and  Maintenance  Data 
relating  to  the  design  of  the  system  under  maintenance. 


Deficiency  Reports 


Table  ITF.F  A3,  SUMMARY ,  TOP  (sheet  ?  of  ?) 


A3  Glossary  (Con't) 

On-Condition  Recording  - 

T.O.  Procedure,  Physical /Functional  Design  Description 
T.O.  Procedures,  Design  Description  - 


IDEF  A3  CONCEPT  PAPER 


CALS  FOR  MAINTENANCE 

1.  FOCUS  ON  CALS  IMPLEMENTATION 

1.1  Overview .  Battle  2000  concepts  envision  high  mobility, 
battle  on  the  run,  the  possibility  of  chemical  or  biological  war¬ 
fare,  coupled  with  limited  quantities  and  unpredictable  locations 
of  forward  bases,  support  resources  and  trained  personnel.  The 
conditions  under  which  maintenance  must  be  performed  will 
consequently  be  so  severe  that  neither  conventional  maintenance 
instructions  nor  maintenance  resources  will  suffice. 

Technicians  will  be  required  to  perform  repairs  with  little 
or  no  training  for  the  particular  task.  In  addition,  the  next 
generation  of  weapon  systems  will  feature  extensive  use  of  micro 
electronics  in  avionics,  control  systems,  and  built-in  sensing 
and  monitoring  of  equipment  condition.  Even  mechanical  systems 
(such  as  aircraft  flight  control  surfaces)  will  be  configured  by 
computers  as  necessary.  The  architecture  of  these  self¬ 
programming  systems  will  involve  basic  components  (e.g.,  power 
supply)  that  are  automatically  reconfigured  into  different 
subsystems  as  needed,  to  perform  multiple  functions  during  a 
mission,  and  to  work  around  failed  components.  A  new  maintenance 
decision  is  added:  whether  to  fix  such  a  system  or  let  it 
continue  to  operate  and  degrade.  Maintenance  will  be  more 
complex  (fewer  packaged  "big  black  boxes"  to  pull)  and  require 
software  as  well  as  hardware  maintenance.  Component  reliability 
will  be  much  higher  and  more  uniformly  distributed,  which  leads 
to  a  paradox  in  that  fault  isolation  becomes  less  reliable, 
because  when  reliability  of  sensor  and  sensed  are  similar  it  is 
more  difficult  to  have  confidence  in  failure  location. 

Battle  damage  which  by  its  very  unpredictability  and 
multiple  simultaneous  faults  is  not  normally  accurately  assessed 
or  located  by  Built-In-Test  programs  must  be  properly  diagnosed, 
corrected,  or  otherwise  dispositioned.  Computerized  maintenance 


aids  will  provide  for  effective  mai nte nance  under  these  austere 
circumstances,  resulting  in  quicker  maintenance  turn-around,  and 
higher  confidence  in  successful  repair  than  otherwise  possible. 


1 .2  Projected  Performance  of  the  Target  Computerized  Func¬ 
tions  .  Assuming  that  the  weapon  system  is  designed  to  include 
the  appropriate  supportability  design  attributes  discussed  under 
"CALS  Interaction  with  Equipment  Des ign/Mod i f icat ion"  it  remains 
to  provide  maintenance  aids  beyond  those  contained  in  the  weapon 
system,  as  determined  and  optimized  by  integrated  diagnostics 
analyses.  There  are  three  distinct  elements  involved  in 
providing  automated  aids: 

a.  An  authoring  system  used  by  the  contractor  (and  perhaps 
the  Service)  to  create  and  update  the  information  in  appropriate 
format,  as  well  as  provide  adequate  configuration  and  quality 
control . 

b.  A  storage  and  distribution  system  used  by  the  Service 
to  accept  the  information  from  the  authoring  system,  store, 
practice  configuration  control,  and  reproduce/transmit  it  for  the 
user . 

c.  A  user’s  display  system  to  access  needed  data  (and 
record/ feedback  for  transmission  back  up  the  chain). 

The  title  "aids"  rather  than  "instructions"  is  used  for  this 
section  to  emphasize  that  future  electronic  systems  need  not  be 
bound  by  these  constraints. 

1.3  Implementation  Considerations. 

The  maintenance  aids  system  is  envisioned  to  consist  of  a 
small  portable  terminal  with  which  the  technician  can  access 
maintenance  information  in  an  interactive  fashion  for  any  type  of 
repair  task  or  battle  damage  assessment. 

Several  different  approaches  to  a  display  system  are 
currently  being  pursued  in  Service  R&D  programs.  These  include 


live  photographic  action  on  video  disc,  multi-level  procedures 
with  pertinent  line  drawings  stored  in  portable  digital 
electronic  displays,  diagnostic  logic  models,  and  artificial 
intelligence  software  that  operates  from  the  engineering  data 
base.  The  type  of  authoring  and  communication  needed  will  depend 
in  part  on  the  display  approach.  More  research,  experimentation, 
and  field  trial  experience  is  needed  to  find  out  what  form  of 
displays  are  best  for  specific  situations.  For  example,  there  is 
evidence  that  simple  line  drawings  that  extract  and  highlight  the 
key  information  are  more  effective  than  full  fidelity 
photographic  pictures  for  illustrating  maintenance  sequences. 
However,  this  might  not  hold  true  for  initial  training  on 
equipment  location. 

For  the  near  future  there  will  likely  be  several  different 
approaches  tried  in  the  three  Services.  Eventually  these  will 
evolve  into  a  system  in  which  the  contractor  uses  CAD-type 
technology  and  artificial  intelligence  aids  for  efficient 
technical  data  authoring,  quality  control,  and  configuration 
management.  The  authoring  software  must  facilitate  the 
integration  and  process  control  of  information  drawn  from  the 
engineering  data  base  and  prepared  by  different  writers.  The 
Services  will  establish  standards  for  electronic  receipt  of  these 
data,  a  standard  data  base  manager  to  store,  update  and  control 
the  resident  data,  and  standards  and  new  communication  capability 
to  transmit  large  volumes  of  new  data  and  updates  to  the  field. 
This  could  be  by  satellite  data  links.  At  some  central  field 
locations  the  data  update  transmissions  will  be  converted  to  the 
appropriate  storage  from  (e.g.,  hard  disc,  optical  disc,  etc.) 
for  distribution  to  the  local  users.  The  maintenance  technicians 
or  operators  will  display  the  data  on  their  transportable  or 
imbedded  display  computers.  These  computers  will  have  diagnostic 
and  AI  capability,  and  communication  links  to  available  weapon 
system  data  bases. 


1.4  Likely  Payoffs.  The  computer  can  handle  the  cross- 
referencing  relationships  for  rapid,  transparent  access  to  all 
parts  of  the  data  base  for  transmission  to  the  technician’s 
display.  This  will  permit  multiple  levels  of  detail  and 
presentation  tailored  to  the  skill  of  the  user.  The  computer  can 
perform  functions  such  as  schematic  tracing  and  parts 
identification  and  can  assist  in  providing  dynamic  trouble¬ 
shooting  logic  and  augment  the  data  base  with  the  result  of  each 
new  use.  The  automated  aid  becomes  an  interactive  assistant 
rather  than  a  static  instruction.  The  distinction  between  test 
equipment,  maintenance  aids,  and  training  materials  disappears. 

In  the  future  it  will  be  possible  to  have  a  single  device  and 
inherent  software  that  would  perform  diagnostics,  aiding,  or 
training  as  needed.  In  some  cases  this  could  even  be  imbedded  in 
the  prime  equipment. 

The  payoff  will  be  properly  maintained  equipment  even  in 
austere  conditions,  less  spares  depletion  due  to  drastic 
reduction  in  maintenance  errors,  and  potential  for  work-a-round 
procedures  developed  by  artificial  intelligence  systems  using  up- 
to-date  complete  design  information  residing  in  a  rapidly 
interrogated  data  base.  These  in  turn  will  have  the  effect  of  a 
force  multiplier,  increasing  sortie  rates  and  decreasing  life 
cycle  costs. 

1.5  Changes  Needed  and  Problems.  The  conditions  under  which 
maintenance  will  be  performed  will  be  very  severe.  Test 
equipment  will  be  required  to  be  miniaturized  and  highly  mobile. 
Electronic  warfare  will  restrict  and  disrupt  communications, 
whereas  chemical/biological  warfare  will  put  new  constraints  on 
man-machine  interfaces  with  information  systems.  Battle  damage 
repair  will  require  access  to  more  extensive  engineering  data 
than  normally  provided  in  technical  orders.  Ideally,  an 
improvised  damage  repair  should  be  analyzed  to  determine 
operating  limits,  by  the  same  kinds  of  techniques  as  used  in 
design  analyses. 


Any  military  system  must  be  designed  for  use  in  war  as  its 
primary  objective.  This  means  consideration  of  resiliency  and 
redundancy  against  loss  of  any  single  element,  and  the  ability  to 
withstand  environments  such  as  chemical  and  electronic  warfare, 
and  be  operable  by  technicians  in  chemical  protection  gear.  The 
system  should  be  buffered  at  each  element  so  that  any  breakdown 
is  not  catastrophic.  The  user’s  display  should  be  operable 
independent  of  transmission  from  the  central  storage,  which  is 
only  used  periodically  to  transmit  updates  and  feedback. 

2.  IDENTIFICATION  OF  CANDIDATE  FUNCTIONS 

2.1  Maintenance  Management.  Automation  can  be  used  to  make 
maintenance  management  much  more  efficient  and  effective. 
Opportunities  include  the  availability  of  on-cond i t 5  on  data  from 
the  weapon  system,  access  to  historical  data  banks  to  detect 
trends,  use  of  computers  to  analyze  the  effectiveness  of 
processes  and  procedures,  tracking  of  resource  status,  optimal 
job  sequencing,  and  positive  configuration  control  of  equipment. 
The  interface  with  the  supply  system  should  provide  for  automatic 
parts  ordering,  status  determination,  and  better  decisions  on 
cannibalization  and  transfer  to  higher  maintenance  levels.  The 
Air  Force  has  an  automated  maintenance  system  prototype  in 
operation  at  Dover  Air  Force  Base  that  is  a  first  step  toward 
capitalizing  on  these  automation  opportunities. 

2.2  Automated  Repair,  Servicing,  and  Maintenance  Aids.  Paper- 

based  instructions  on  how  to  operate  and  maintain  military 
systems  have  been  constrained  by  the  paper  media  to  a  rigid, 
fixed  format.  In  order  to  keep  volume  and  cost  down,  any  single 
instruction  was  presented  only  one  way.  Troubleshooting 
instructions  were  procedural  or  in  a  fixed  format  (e.g.,  through 
a  fault  tree).  These  had  severe  problems  in  that  they  were 
generally  too  narrow  to  address  all  possible  problems;  neither 
were  they  sufficiently  accurate  because  they  could  not  address 
and  check  cause  and  effect  as  thoroughly  and  accurately  as  a 
computer.  A  computer  does  not  need  to  "project”  the  potential 
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problem.  Instead,  the  computer  can  analyze  a  problem  at  the  time 
it  occurs  from  the  design  information  available  to  it. 

Therefore,  this  type  of  automatic  fault  isolation  and  repair 
procedure  development  is  highly  recommended. 

3.  ANTICIPATED  RECOMMENDATIONS 

3.1  Automated  Display  Device.  Many  of  the  functional 
distinctions  we  have  been  used  to  should  break  down  when  the 
integration  opportunities  of  automation  and  miniaturized 
electronics  are  fully  exploited.  The  functions  of  a  test  set  and 
an  automated  technical  data  display  can  be  performed  by  the  same 
portable  device.  When  connectors  are  standardized,  the  same 
device  may  also  do  go-no-go  checks  on  removed  components. 

3-2  Automated  Diagnostics.  Deep-logic  artificial  intelligence 
diagnostics  will  operate  off  the  same  engineering  data  base  used 
for  failure  modes  analysis  in  design.  CALS  will  need  to  include 
mechanisms  for  keeping  these  data  current  and  available  as  a 
source  for  artificial  intelligence  programs  used  for  diagnostics 
in  the  field.  This  will  introduce  new  configuration  management 
responsibilities  to  control  both  configuration  changes  and 
failure/mode  effect  changes  that  feedback  from  field  experience. 

3.3  Software  Integration.  Software  integration  and 
configuration  control  will  become  a  much  more  significant 
workload.  Not  only  will  more  of  the  weapon  system  maintenance 
involve  fixes  to  software,  but  all  the  data  bases  that  should  be 
available  to  the  technicians  and  maintenance  management  must 
maintain  information  and  communication  capability.  An  example  of 
the  potential  set  for  Air  Force  maintenance  is  shown  in  Figure  2- 
37.  This  is  a  major  challenge  for  CALS  in  maintenance. 
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PFR^ORM  MODIFICATION 


Table  2-25.  IDEF  A4,  SUMMARY,  COD  (sheet  1  of  2) 


A4  Perform  Modification 


Glossary 

Config.  Mgmt  (TO/CMS)  -  Technical  Data/Configuration  Management  System  a 
software  program  which  controls  configuration  and  changes  thereto. 

Orig.  TDP/MDP  -  Tech  Data  Package/Manufacturing  Data  Package. 

Tech  Spec  -  The  technical  requirements  in  the  contract. 

Redesign  Rqmt  -  An  identified  need  to  re-engineer  an  item  based  on  new 
technology  or  reported  deficiencies. 

Revised  Design  Data  Pkg  (TDP/MDP/Manual s)  -  Data  which  accompanies  equipment 
to  be  modified  or  remanufactured. 

Config.  Mgmt  (CM)  -  The  control  of  the  hardware/software  configuration  and 
its  relationship  to  the  data  package. 

Engr  Change  Proposal  (ECP)  -  Proposal  to  change  the  engineering  design  of 
equipment,  based  on  new  technology  or  field  performance  feedback. 

Product  Improvement  Program  -  Designed  to  improve  performance  or  enhance 
reliability  and  maintainabi 1 lty. 

Contract  Authority  -  Procurement  office  with  approval  authority  to  initiate 
contractual  modifications. 

Field  Performance  Feedback  From  Users  -  Information  from  equipment  users 
regarding  equipment  performance  history. 

New  Tech  Data  -  New  technological  data  available  from  research  labs. 

Cost  Data  -  Information  on  the  cost  of  the  item  of  service. 

Shipping  Data  -  Information  needed  to  transport  the  item. 

Inventory  Data  -  Information  on  material  in  inventory. 

DMWR  -  Depot  Maintenance  Workload  Requirement  -  tasking  document  to  the  DOD 
depot  for  modification/maintenance  work  to  be  performed. 

Contract  -  That  document  under  which  the  Contractor  is  performing. 

Change  Authority  -  Configuration  control  authority. 

Schedule  Data  -  Program  data  that  schedules  the  application  of 
modifications. 

Re-Issue  Data  -  Data  resulting  from  completion  of  required  modifications  as 
equipment  is  re-issued  to  the  user. 
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Table  P-25. 


IDRF  AH,  SUMMARY,  DOD  (sheet  2  of  2) 


A4  Glossary  (Con't) 

Configuration  Change  Data  -  Information  resulting  from  approved  changes  to 
existing  configuration. 

Modification  Work  Order  (MWO)  -  Documentation  used  to  initiate  the 
performance  of  the  modification  process. 


IDEF  A4  DESCRIPTION 


PERFORM  MODIFICATIONS 

CURRENT  STATUS 

Generate  Redesign  Requirement 

Field  Performance  Feedback  from  users 

New  Technology  Data  from  Equipment  Manufactures 

Redesign  Item 

Based  on  Redesign  Requirement 

Engineering  Change  Proposal 
Product  Improvement  Program 

Uses  technical  specification  and  original 
technical  data/manufacturing  data  package 

Remanufacture  Item 

Based  on  Revised  Design  Data  Package 
Based  on  Schedule  Data 

Perform  Field  Modification 

Based  on  Change  Authority 
Executed  via  Modification  Work  Order 

PRINCIPLES  &  CHARACTERISTICS  OF  TARGET  SYSTEM 

Need  for  automated  deficiency  reporting  systems, 
tracking  systems  and  management  information  reports 

Needed  to  generate  and  validate  modification 
requirements 

Needed  to  program  resources 
Needed  to  apply  modifications 

Introduce  CAD/CAM  into  modification  process 

Assess  DOD  needs  to  develop  capability  to  accept 
CAD/CAM  data  electronically  from  contractors 


Engineering  data  to  be  stored  digitally  on  optical  disc 
based  storage  and  retrieval  systems 

DOD 

o  BENEFITS 

Optical-disc  based  storage  systems  for  engineering  data 
to  accelerate  the  preparation  of  tech  data  packages 

Automation  of  reporting  systems: 

Reduce  paperwork 

Provide  greater  capability  to  track 
implementation/application  of  approval  modes 

Allow  better  tracking  of  total  weapon  system  cost 


PROBLEMS 


r 

DOD  must 

o 

IMPLEMENTATION 

r>' 

Implement 

In 

engineer i 

Survey  ex 

systems 

DOD  and  Services  must  determine  how  to  use  CAD/CAM  data 
in  performing  equipment  modification 

DOD  must  define  where  new  applications  will  be  used 


Determine  where  automation  provides  greatest  benefits 

Initial  pilot  demo  to  show  how  Services  can  standardize 
procedures  or  acceptance  of  digitized  CAD/CAM  data 


IMPLEMENTATION  COST 

Acquisition  costs  for  Services  to  obtain  optical  disc 
based  sot rage  systems 

Automation  of  modification  reporting  systems 

Cost  of  pilot  demonstrations  using  digitized  CAD/CAM 
data  to  be  quantified. 
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Table  2-26.  IDFF  A5,  SUMMARY,  DOD 


A5  Perform  Test  &  Evaluation 


G1  ossary 

Regulations/Budget  -  Controlling  functions  for  the  performance  of  test  and 
evaluation. 

Personnel  -  Test  personnel . 

Resources  -  That  which  is  needed  to  perform  the  testing,  including  staff, 
tools,  support  equipment,  facilities,  material,  budget,  etc. 

Test  Plan/Procedures  -  The  documents  which  govern  the  testing  program. 

Opeval  Certification  Final  Specs  -  The  specified  requirements  dictating  the 
performance  and  maintenance  parameters  to  be  evaluated  during 
Operational  Evaluation. 

Test  Data/Results  -  That  data  which  is  developed  and  evaluated  during  and  at 
the  conclusion  of  the  test. 

Personnel,  Facilities  Support,  Hardware,  Software  Funding,  Functional 
Testing,  Test  Group  -  The  required  resources  to  perform  test  and 
evaluation,  its  planning  and  the  preparation  of  the  report. 

Test  Reports  -  The  results  of  the  test  in  report  form. 


IDEF  A5  DESCRIPTION 


CALS  UTILITY  FOR  TEST  AND  EVALUATION,  IDEF,  DOD 

CURRENT  STATUS 

Primarily  hard  copy 

Inputs 

Controls 

Outputs 

Resources  management  primarily  manual 

TARGET  SYSTEM  CHARACTERISTICS 

Automated  (soft  copy) 

Inputs 

Outputs 

Controls 

Automated  resource  management 

BENEFITS 

Expedites  planning,  acquisition,  and  management  process 

More  cost-effective  utilization  of  corporate  resident 
in  data  base 

Faster  adjustment  of  acquisition  strategies  in  response 
to  changing  requirements 

Immediate  availability  of  configuration  change  control 
data  enhances  data  system  currency 

PROBLEMS 

Compatibility  of  contractor  and  Government  data  systems 
Availability  and  compatibility  of  contractor  data 


Proliferation  of  high  capacity  PCs  promotes  creation 
and  utilization  of  individualized  unique  systems 
exacerbating  the  centralized  control  and  coordination 
problem 


IMPLEMENTATION  APPROACH 

Standardize  specifications  imposed  by  Services  on 
contractors  for  automation  of  deliverable  technical 
data 

Services  establish  own  automation  capabilities  to 
utilize  and  mesh  with  contractors  automation  systems 

Establish  DOD  oversight  of  Service  activities  in  this 
area  and  provide  specific  DOD  direction 

Provide  adequate  funding 


IMPLEMENTATION  COST 

The  approach  is  too  MACRO  at  this  point  for  any  kind  of 
useful  cost  estimate 


IDEF  A5  CONCEPT  PAPER 


CALS  UTILITY  FOR  TEST  AND  EVALUATION 

1.  FOCUS  OF  CALS  IMPLEMENTATION 

1.1  Overview.  There  are  two  principal  types  of  logistics  T&E: 
Development  Test  and  Evaluation  (DT&E),  to  verify  contract 
technical  specification  requirements,  and  Operational  Test  and 
Evaluation  (OT&E),  which  evaluates  operational  effectiveness  and 
Service  suitability  of  new  systems  and  components. 

Advanced  computer  capabilities  and  networking  procedures 
make  possible  direct  links  between  Government  and  contractor  test 
data  files.  Programs  can  be  written  which  will  assess  test  data 
inputs,  identifying  inconsistencies  which  forecast  developing 
problems.  The  program  will  identify  causes  and  corrective 
actions.  During  the  analysis,  the  computer  will  have  all  the 
necessary  communication  links  established  for  interfacing  with 
the  contractor’s  data  bases,  thereby  integrating  all  relevant 
design  information  for  problem  solving. 

This  test  capability  will  be  cost  effective  and  will  reduce 
evaluation  time.  It  will  assist  the  Test  Director  in  analyzing 
problems  and  measuring  their  impact  on  the  test  program. 

This  automation  capability  will  be  used  to  evaluate  the 
previously  conducted  contracted  tests  using  the  results  to  modify 
the  Government  test  plan  to  reduce  redundancies  and  highlight 
questionable  areas  for  priority  attention. 

1.2  Benefits .  Systems  engineering  risks  will  be  significantly 
reduced  this  test  emulation  which  can  be  used  prior  to  actual 
test . 


1.3  Changes  Needed  and  Anticipated  Problems.  Standardization 
to  provide  software  interfaces  which  will  ensure  the  availability 


of  compatible  global  data  communications  is  required  so  that 
problems  encountered  during  technical  evaluations  may  be 
addressed  in  real  time. 

2.  IDENTIFICATION  OF  CANDIDATE  FUNCTIONS 

Computerized  system-level  simulations  will  verify  the 
capability  of  the  proposed  design  to  provide  the  required  mission 
performance  to  assess  risk  in  testing  prior  to  large  expenditures 
in  a  test  program. 

3.  ANTICIPATED  RECOMMENDATIONS 

3.1  Funding  Issues.  In  order  to  successfully  adapt  CALS  to 
Government  T&E,  testing  requirements  must  be  integrated  with 
budgeting  and  financing  procedures.  Methodologies  for  accurate 
and  early  T&E  cost  forecasting  are  required  and  a  formal 
feasibility  study  of  the  automation  of  DT&E/OT&E  test  procedures 
should  be  undertaken  as  soon  as  possible. 

3.2  Incentive  Issues.  Accelerated  development  of  CALS  for  T&E 
requires  funding  for  exploratory  development  of  T&E  areas 
requiring  state-of-the-art  advancement  and  for  concept 
formulation  efforts. 

3-3  Contracting  Issues.  The  major  contracting  issues  will 
result  from  the  use  of  obligatory  standard  computerized  Support 
Acquisition  and  Management  techniques  which  will  impact  upon 
contractual  regulations.  The  Government  must  specify  compatible 
automated  Test  and  Evaluation  procedures  in  Requests  for  Proposal 
(RFPs),  otherwise  the  Services  will  need  to  tailor  their 
techniques  to  be  compatible  with  a  variety  of  industries. 

3.4  Specifications  and  Standards  Issues.  Specifications  and 
standards  issues  must  be  addressed  at  the  outset  to  prevent  a 


proliferation  of  independent,  stand-alone  models — a  condition 
which  would  inhibit,  if  not  prevent,  interoperability  among 
potential  users.  One  way  to  ensure  compatibility  will  be  to 
retain  the  manual  procedures  for  T&E  while  transitioning  to 
computer  aided  techniques.  This  will  permit  existing 
specifications  and  standards  to  be  modified/adjusted  concurrent 
with  the  preliminary  development  of  automated  programs. 

3.5  Technological  Changes.  The  projected  advances  in  computer 
technology,  data  management  and  exchange  techniques,  and 
communications  methods  should  encourage  the  rapid  introduction  of 
an  automated  Test  and  Evaluation  support  concept  for  both 
Government  and  industry. 

3.6  Policy  Issues.  Requiring  the  services  to  implement  and 
utilize  standard  computerized  T&E  support  techniques  during 
systems  test  phases  will  require  modification  to  the  test 
procedures  and  policies. 

4.  JUSTIFICATION  FOR  THE  CHOICE  OF  CANDIDATES 

4.1  High  Payoff.  The  T&E  candidates  for  automation  will 
provide  the  opportunity  for  substantial  cost  benefits  in  terms 
of: 

Paper  reduction. 

Improved  data  accuracy,  and 
Improved  data  availability. 

Cost  benefits  in  paper  reduction  alone  will  justify 
automating  T&E  procedures  for  systems  support.  In  addition  to 
the  savings  realized  by  reducing  and/or  eliminating  reports, 
plans,  etc.,  a  potential  exists  for  significant  reduction  in  the 
cost  of  filing  and  storing  paper  documents. 
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4.2  Feasibility .  The  concept  of  fully  automated  techniques 

for  T&E  procedures  is  well  within  the  realm  of  functional 
feasibility,  given  the  present  state-of-the-art  electronic  data 
processing  technologies.  The  proliferation  of  decentralized, 
nonstandard,  and  relatively  inexpensive  computer  aids  will 
quickly  lead  to  the  Government’s  ability  to  develop  and  implement 
automated  T&E  procedures.  The  Government  must  respond  rapidly  to 
this  expanding  phenomenon  and  must  take  full  advantage  of  its 
vast  potential  for  improved  product  quality  and  decreased 
acquisition  leadtimes  and  associated  costs. 


CALS  FUNCTIONAL  DESCRIPTIONS 
DoD  FUNCTIONS: 


7.  IDEF  A6,  Provide  Supply  Support 
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Table  2-27.  IDEF  A6,  SUMMARY,  DOD 


A6  Provide  Supply  Support 


61  ossary 

Policy,  Budget  - 

Demand  -  The  recorded  needs  for  an  item  of  material. 

Scheduled  Need  Date  -  The  date  on  which  an  item(s)  of  inventory  is  required 
to  be  in  place. 

PTD  -  Provisioning  Technical  Data. 

Usage  -  Recorded  data  on  amount  of  use  an  equipment  item  receives. 
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Desired  Location,  Shelflife  (PTO),  Facilities  -  Assignment  of  location  and 
storage  requirements  for  an  item  of  inventory. 

Demand  Schedule,  Cost  -  The  scheduled  replenishment  rate  and  estimated  costs 
from  which  replenishment  items  can  be  acquired. 

Availability  Date  -  The  data  on  which  material  will  be  available  for 
shipment. 

Replenishment  Requirement  -  Material  required  to  replenish  existing  stock  or 
inventory  item. 

Spec  -  Specification  for  the  replenishment  item  for  purpose  of 
rep  rocu  rement . 

MFG  Data  Pkg  -  A  set  of  information  sufficient  to  manufacture  the 
replenishment  item. 

Supplier  Delivery  Schedule  -  Contractor's  schedule  for  delivery  of  material. 

Cost  &  Delivery  -  Cost  and  delivery  information  feedback  to  inventory 
management's  records. 

Order  -  The  process  and  data  used  to  order  material  and  services. 

Delivered  Item  -  Material  item  delivered  from  source  of  supply. 

Transportation  Capability  -  Definition  of  resources  required  to  provide 
transportation  of  material. 

Actual  Location  - 

Item  Issue  - 
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IDEF  A6  CONCEPT  PAPER 


PROVIDING  SUPPLY  SUPPORT 


1.  FOCUS  OF  CALS  IMPLEMENTATION 

1 . 1  Projected  Performance  of  the  Target  Computerized  Functions. 

The  application  of  current  and  evolving  computer  technology, 
combined  with  the  availability  of  CAD  and  CAM  data,  will 
revolutionize  the  traditional  logistics  activities  of 
provisioning  and  supply.  DoD  provisioning  and  supply  activities 
include  the  functions  of  provisioning  technical  documentation 
(PTD)  acquisition,  spare/repair  part  procurement /reprocurement , 
inventory  management  and  storage/distribution.  Provisioning  and 
supply  activities  have  traditionally  been  expensive,  unwieldy  and 
not  particularly  responsive  to  the  needs  of  weapon  system  users, 
managers  or  manufacturers.  The  primary  obstacle  to  resolving 
these  difficulties  has  been  the  impossibility  of  creating, 
processing,  diseminating  and  updating,  in  a  timely  manner,  the 
mountains  of  data  that  are  associated  DoD  provisioning  and  supply 
activities.  With  the  advent  of  technologies  that  provide 
inexpensive  data  storage,  improved  data  communication,  network¬ 
wide  operating  systems  and  distributed  data  bases  this  no  longer 
needs  to  be  a  constraining  factor. 

1.2  Implementation  Considerations.  The  application  of 
existing  and  developing  computer  technology  to  DoD  provisioning 
and  supply  activities  will  significantly  alter  the  manner  in 
which  they  are  performed,  improve  their  cost-effectiveness  and 
make  them  more  responsive  to  the  needs  of  weapon  system  users, 
managers  and  manufacturers.  Although  the  means  of  accomplishment 
will  be  altered,  very  little  new  data  will  be  required.  Rather, 
the  same  data  that  are  currently  required  will  be  needed  in  a 
different  format  or  on  a  different  media. 
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Though  industry  is  capable,  and  in  many  cases  has  switched  to 
automatic  techniques  and  utilization  of  the  LSAR  for  spares 
projection  and  listings,  the  Services  have  not  yet  accepted  the 
techniques.  Provisionings  is  still  performed  the  "old  way".  No 
degree  of  improvement  on  the  side  of  the  contractor  will  engender 
an  overall  improvement  until  the  Services  modernize  and  actually 
use  the  automated  techniques  specified  for  the  contractor's  use. 

1.3  Likely  Payoffs.  In  the  provisioning  technical  document¬ 
ation  arena,  the  application  of  these  technologies  will  result  in 
the  streamlining  and  standardization  of  the  preparation/submittal/ 
review/approval  process.  The  remaining  paper  flow  associated  with 
PTD  activities  will  be  replaced  with  exchanges  of  digital  media 
and  eventually  with  direct  industry  to  DoD  system  communication. 

At  the  same  time,  the  process  that  has  been  initiated  with  the 
development  of  MIL-STD-1 388-2A  will  result  in  a  standard  industry- 
to-DoD  provisioning  data  format  for  all  DoD  components.  PTD 
efforts  will  increasingly  be  an  integral  part  of  the  LSA/LSAR 
effort  and  will  make  extensive  use  of  CAD/CAM  parts  list  data. 

PTD  screening  activities  will  diminish  in  size  and  importance  as 
data  on  parts  presently  in  Government  inventory  (Defense  Logistics 
Supply  Center  data)  are  made  more  readily  available  to  industry 
and  are  integrated  with  CAE  and  CAD  parts  selection  and 
standardization  systems.  Traditional  illustrated  parts  breakdown 
manuals  (IPBs)  and  repair  parts  and  special  tools  lists  (RPSTLs) 
will  be  replaced  with  on-line  computer  data  bases  that  provide  DoD 
personnel  with  all  necessary  data  concerning  appropriate  spare  and 
repair  parts. 

The  spare/repair  parts  procurement  function  will  also  undergo 
significant  changes.  The  present  manual  and  semi-automated  spares 
delivery  tracking  systems  will  be  replaced  with  on-line  systems 
that  are  regularly  updated  with  information  from  industry  systems. 
These  updates  will  initially  be  performed  utilizing  data  that  are 
transfered  utilizing  removable  computer  media.  Use  of  removable 


media  for  data  transfer  will  eventually  be  phased  out  and 
replaced  with  direct  communication  between  DoD  and  industry 
computer  systems.  The  present  difficulties  encountered  with 
acquisition  and  maintenance  of  reprocurement  data  will  be 
surmounted  through  implementation  of  a  variety  of  improved 
capabilities  and  as  a  by-product  of  changes  that  are  occuring  in 
several  other  areas.  Included  among  the  improved  capabilities 
are  automation  of  DoD  data  repositories  to  allow  improved 
retrieval  of  existing  engineering  data,  procurement  of  new 
engineering  data  in  computer  sensible  formats  that  are  more 
accurate  and  easier  to  store,  retrieve  and  update  than  paper 
media,  and  increased  use  of  contractor  data  and  personnel  to 
facilitate  identification  of  acceptable  substitute  and  lower  cost 
replacement  items.  Benefits  will  also  accrue  from  changes  that 
are  occuring  in  the  parts  standardization  area  and  as  a  result  of 
industry  movement  to  the  use  of  CAE  and  CAD  systems.  Increased 
use  of  standard  and  existing  inventory  parts  will  decrease  the 
volume  data  that  must  be  acquired  and  maintained,  while  the 
movement  to  CAE  and  CAD  systems  will  result  in  better  designs 
that  have  fewer  unique  configurations  and  that  require  fewer 
retrofit  and  modification  actions.  The  present  "problem"  of  high 
cost  spares  and  support  equipment  will  disappear  as  weapon  system 
designers  make  greater  use  of  standard  parts,  DoD  systems  provide 
improved  schedule  and  cost  visibility  to  system  managers  and 
incentives  are  put  in  place  for  industry  to  design  systems  that 
minimize  the  need  for  expensive  and  unique  spare  parts. 

The  task  of  inventory  management  will  be  greatly 
streamlined.  On-line  inventory  management  systems  will  provide 
improved  visibility  of  inventory  status,  consumption  rates  and 
locations.  These  systems  will  allow  DoD  personnel  to  spot 
developing  support  problems  and  initiate  resupply  and  procurement 
actions  in  a  timely  manner.  Improved  visibility  of  inventory 
location  will  allow  system  managers  to  make  the  best  use  of 
available  assets  and  to  eliminate  the  problem  of  inadvertent 


asset  disposal.  When  coupled  with  improved  feedback  of  field 
experience  data,  these  systems  will  allow  system  managers  to 
identify  high-payoff  areas  for  modification  and/or  redesign. 
Weapon  system  users  and  supply  activities  will  benefit  from 
implementation  of  these  systems  by  being  able  to  quickly  locate 
needed  items  and  obtain  current  information  concerning  on-order 
items . 

The  storage  and  distribution  function  will  also  change  as  a 
result  of  the  application  of  computer  technology.  Input  from  the 
inventory  management  systems  and  feedback  from  analysis  of  field 
experience  data  will  allow  identification  of  such  storage  and 
distribution  problems  as  inadequate  quantity  allocations, 
excessive  shipping  times  and  excessive  shipping  co~ts.  In  the 
same  way,  inventory  costs  will  be  reduced  through  timely 
identification  and  disposal  of  un-needed  items  and  more  effective 
management  of  calibrated  and  limited  life  components. 


Annex  3 


RECOMMENDED  DEMONSTRATIONS 

#  1  Digital  Delivery  of  Technical  Publications . 

#2  Interactive  Diagnostic  and  Maintenance  Aids . 

#3  RAMCAD . 

#4  Automated  LSAR  Input . 

#5  Automation  of  Classic  Logistic  Data  Item . 

#6  Computer-Aided  Specification/RFP  Preparation . 
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2.  Objective.  Develop  and  demonstrate  a  tri-Service  capability 
to  contractually  specify  and  accept  delivery  of  contractor 
developed  technical  publications  in  a  digital  format. 

3.  Description-  As  discussed  in  the  CALS  Concept  Paper  on 
preparation  of  maintenance  and  operation  data,  near-term 
improvement  of  the  DoD  technical  publication  system  will  be 
achieved  through  implementation  of  industry  and  DoD  computing 
systems  to  aid  the  authoring,  delivery,  maintenance  and 
distribution  process.  Such  systems  will  be  composed  of  three 
major  elements,  industry  authoring  systems,  a  computer-sensible 
deliverable  data  format  and  DoD/Service  archive,  update  and 
delivery  systems.  Figure  4-1  presents  a  conceptual  diagram  of 
how  such  a  system  would  operate.  Of  the  three  major  near-term 
system  elements,  the  most  time  critical  is  the  development  of  the 
computer-sensible  deliverable  product.  The  reason  for  this  is 
that  both  industry  and  the  Services  are  currently  planning  and 
implementing  computer  systems  to  perform  these  functions. 

Without  a  standard  data  exchange  format,  industry  systems  that 
are  oriented  toward  production  of  plate  negatives  will  continue 
to  be  implemented  and  Service  systems  will  each  have  their  own 
unique  data  format.  This  will,  in  turn,  require  that  each 
industry  system  have  and  maintain  the  capability  to  output  to 
each  Service  system  that  will  utilize  its  data.  It  will  also 
require  replacement  or  modification  of  much  of  the  computing 
capabilities  that  are  being  put  in  place  to  produce  plate 
negatives.  Near  term  development  and  implementation  of  a 
computer-sensible  deliverable  data  format  is  the  most  effective 
means  available  to  guide  the  near-term  development  of  government 
and  industry  computerized  publication  systems,  ensure  that  these 
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Figure  4-1.  NEAR-TERM  TECHNICAL  PUBLICATIONS  SYSTEM  CONCEPTUAL  DIAGRAM 


systems  can  exchange  data  with  each  other,  and  minimize  the  total 
investment  that  must  be  made  in  these  near-term  capabilities. 

Development  of  a  computer-sensible  deliverable  data  format 
should  proceed  as  depicted  in  Figure  H-2.  The  following  sections 
discuss  each  of  the  project  elements.  They  are  presented  in  the 
order  that  they  should  be  performed. 

a.  Document  Data  Requirements.  This  task  is  needed  to 
establish  a  firm  baseline  for  evaluation  and,  if  necessary, 
development  of  acceptable  data  exchange  standards.  The  starting 
point  for  this  effort  would  be  the  present  technical  publication 
specifications  and  standards.  It  is  anticipated  that  this  effort 
would  draw  heavily  upon  the  Tri-Service  Technical  Manual 
Specifications  and  Standards  (TMSS)  consolidation  effort  that  is 
currently  in  progress.  The  product  of  this  task  would  be  a 
concise  statement  of  technical  publication  data  requirements. 

b.  Survey  Industry  Systems  and  Plans.  In  order  to 
minimize  the  cost  of  implementing  a  new  data  exchange  format,  it 
is  necessary  to  develop  an  accurate  picture  of  the  current 
hardware  and  software  base,  and  understand  the  direction  of  its 
evolution.  The  project's  second  task  is,  therefore,  to  conduct  a 
comprehensive  survey  of  current  industry  systems  and  future 
plans.  The  product  of  this  task  would  be  a  document  describing 
current  industry  computerized  publication  systems  and  the 
direction  that  they  are  evolving. 

c.  Survey  of  Service  Systems  and  Plans.  Just  as  with 
industry,  a  comprehensive  understanding  of  current  Service 
activities  must  be  developed  in  order  to  minimize  costs.  The 
third  project  task  is,  therefore,  to  survey  current  and  planned 
service  technical  publication  computerization  efforts.  The 
product  of  this  task  would  be  a  document  describing  current  and 
planned  service  computerized  publication  systems  and  the 


Figure  4-2.  DIGITAL  DELIVERY  OF  TECHNICAL  PUBLICATIONS  DEMONSTRATION 

PROJECT  SCHEDULE 


Identification  and  Evaluation  of  "de  facto"  and 


Evolving  Standards.  Prior  to  developing  new  data  exchange 
standards,  consideration  should  be  first  given  to  the  possibility 
of  adopting  existing  de  facto  or  evolving  data  exchange 
standards.  Accordingly,  the  fourth  project  task  is  to  identify 
and  evaluate  these  type  of  standards.  The  most  often  mentioned 
de  facto  standards  in  this  area  are  the  National  Bureau  of 
Standards  IGES  and  Graphic  Communications  Association's  GENCODE 
efforts.  The  product  of  this  task  would  be  a  determination  of 
the  practicality  of  utilizing  existing  or  evolving  standards  for 
the  transfer  of  computerized  technical  publication  data. 

e.  Develop  and  Coordinate  Data  Exchange  Standards 
Recommendations .  Completion  of  the  first  four  project  tasks 
provides  the  basis  for  accomplishment  of  task  five,  development 
of  data  exchange  standards  recommendations.  These 
recommendations  would  be  developed  by  evaluating  the  impact  of 
standards  deemed  suitable  under  task  four  on  current  industry  and 
Service  efforts.  Where  the  impact  is  too  great,  suitable 
standards  do  not  exist,  or  modifications  are  needed,  recom¬ 
mendations  would  be  made  concerning  appropriate  modification/ 
development  efforts.  These  recommendations  would  then  be 
coordinated  with  the  appropriate  industry  associations  and 
Service  agencies.  The  product  of  this  task  would  be  definitive 
recommendations  concerning  adoption  of  existing  standards,  needed 
changes  to  existing  standards,  and  development  of  new  standards. 

f .  Develop  (if  required)  New  Data  Exchange  Standards. 

Under  task  six,  any  development  or  modification  effort 
recommended  as  a  result  of  task  (e)  would  be  completed.  The 
product  of  this  task  would  be  the  completed  data  exchange 
standards  and  any  software  required  to  implement  them 
(translators,  validation  routines,  etc.) 


g.  Demonstrate  Industry-to-Service  Data  Exchange  Using  the 
Recommended  Standards .  Task  (g)  would  demonstrate  the  use  of  the 
recommended  data  exchange  standards  to  exchange  technical 
publication  data  between  industry  and  Service  systems.  In  order 
to  provide  a  high  degree  of  confidence  in  their  usability,  data 
exchanges  would  be  performed  between  multiple  industry  and 
service  systems,  and  would  be  performed  in  both  directions. 

h.  Finalize  and  Publish  Data  Exchange  Standards.  Task  (h) 
would  be  to  finalize,  document  and  publish  the  formal  data 
exchange  standards.  The  product  of  this  effort  would  be  a 
comprehensive  set  of  data  exchange  standards  that  could  be 
contractually  implemented. 

4.  What* s  Needed  To  Do  It?  Three  things  are  necessary  to 
complete  this  project:  (1)  a  DoD  level  decision  to  conduct  it, 

(2)  an  appropriately  chartered  and  funded  organization,  and  (3) 
the  support  of  industry  and  the  Services.  The  first  two  items 
require  action  on  the  part  of  DoD.  Industry  support  of  the  third 
would  not  be  difficult  to  secure  due  to  the  high  level  of  current 
interest.  Tri-Service  support  has  traditionally  been  difficult 
to  obtain  and  would  require  some  firm  DoD  direction. 

5.  What  Exists  Today?  A  significant  investment  has  already 
been  made  by  industry  in  computer  hardware  and  software  for 
development  and  production  of  technical  publications.  These 
systems  generally  include  the  elements  of  text  entry,  graphics 
creation,  composition  and  negative  production.  In  addition,  most 
companies  have  plans  in  place  for  upgrade  and  enhancement  of 
these  systems.  Also,  there  is  currently  considerable  activity 
within  the  various  industry  associations  relative  to  development 
of  computer  sensible  data  exchange  standards.  Of  particular 
importance  to  this  project  are  the  ATA  and  NSIA  efforts. 


Each  of  the  Services  also  has  ongoing  efforts  that  are 
related  to  this  project.  Of  particular  interest  are  the  Air 
Force  Automated  Technical  Order  System  (ATOS),  the  Navy  Print  on 
Demand  (NPOD)  and  the  Army  Technical  Manual  Specifications  and 
Standards  (TMSS)  projects. 

6.  What  Does  It  Take  To  Get  Started.  The  only  effort  required 
to  initiate  this  project  is  to  charter  and  fund  an  organization 
to  conduct  it. 


RECOMMENDED  DEMONSTRATION  #2 


1 .  Title:  Interactive  Diagnostic  and  Maintenance  Aids 

2.  Objective.  To  demonstrate  the  design  of  automated 
technical  data  for  diagnostics  and  built-in  sensors/test  as  a 
single  integrated  system. 

The  diagnostics  testing  capability  built  into  the  system  and 
the  diagnostic  testing  capability  built  into  automated  technical 
data  (maintenance  aids)  are  two  aspects  of  the  same  diagnostic 
function.  They  require  a  common  analysis,  common  man-machine 
design  tradeoffs,  and  integrated  design  to  assure  compatab i 1 i ty 
and  effective  troubleshooting  capability.  This  is  increasingly 
important  with  the  new  generation  of  gracefully  degrading 
avionics  operating  off  a  common  data  bus.  Information  for  the 
technician's  decision  to  repair  or  defer,  and  the  repair 
instructions  if  a  repair  is  called  for,  should  be  automatically 
shown  on  the  automated  tech  data  display.  This  should  be  drawn 
from  the  system  state  analysis  in  the  on-board  computer.  If  the 
on-board  analysis  is  ambiguous,  the  technician  should  be  able  to 
use  auxiliary  troubleshooting  aids  in  the  automated  technical 
data  to  stimulate  and  test  the  on-board  system  interactively. 
Unanticipated  failure  modes  or  outcomes  should  be  fed  back  to 
engineering  data  management  for  rapid  update  of  the  diagnostic 
software  in  the  automated  technical  data  display.  Such  an 
integrated  system  will  permit  more  effective  troubleshooting  and 
reduce  false  removals.  This  is  essential  to  move  toward  two 
level  maintenance  concepts. 

3.  Description.  The  AFHRL  Integrated  Maintenance  Information 
System  (IMIS)  diagnostics  program,  outlined  in  this  paper,  will 
develop  and  evaluate  the  diagnostic  portion  of  IMIS  (see  outlined 


area  of  Figure  4-3)  in  conjunction  with  the  Avionics  Laboratory 
PAVE  SPRINTER  Demonstration  Program.  AFWAL/AA  and  AFHRL  will 
jointly  develop  the  diagnostic  system  which  will  consist  of: 

a.  The  portable  computer  (PCMAS)  containing  technical 
order  instructions,  troubleshooting  aids,  historical  and  other 
maintenance  data. 

b.  An  interface  panel  on  the  side  of  the  aircraft, 
allowing  the  technician  easy  access  to  on-board  information. 

c.  The  interface  hardware  and  software  necessary  for  the 
portable  computer  to  communicate  with  on-board  systems. 

d.  The  diagnostic  software  needed  to  integrate  the  on¬ 
board  information  with  technical  data,  stand  alone  diagnostic 
routines,  and  historical  flight  parameter  data. 

4.  Necessary  Programs.  The  diagnostic  system  will  be  developed 
in  two  parts.  The  portable  computer  will  be  developed  by 
enhancing  the  current  design  requirements  for  the  PCMAS  contract. 
The  aircraft  interface  and  diagnostic  software  will  be  developed 
by  adding  an  additional  task  to  the  current  PAVE  SPRINTER 
contract.  At  the  end  of  the  PCMAS  development,  the  portable 
computer  and  associated  software  will  be  provided  as  GFE  to  the 
PAVE  SPRINTER  contractor  for  integration  in  to  the  PAVE  SPRINTER 
flight  test. 

The  current  PCMAS  will  be  developed  to  display  technical 
order  and  battle  damage  assessment  data.  The  contract,  which  is 
planned  to  begin  in  Dec.  84,  will  be  enhanced  to  include  the 
capabilities  needed  for  the  IMIS  diagnostics  effort.  The  design 
requirements  for  the  portable  computer  will  be  expanded  to 
include  the  aircraft  interface  hardware/software,  and  any 
additional  hardware/software  needed  to  provide  the  processing 
capability  to  run  the  diagnostic  software.  The  contract  will  be 
expanded  to  produce  additional  units  of  the  portable  computer, 
and  to  require  the  contractor  to  interface  with  the  PAVE  SPRINTER 
contractor . 


Figure  i*-3.  DIAGNOSTICS  AND  MAINTENANCE  AIDES  FLOW  CHART 
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The  PAVE  SPRINTER  contract  will  be  expanded  to  include  the 
analysis,  design,  development,  and  evaluation  of  the  integrated 
IMIS/PAVE  SPRINTER  diagnostic  system.  The  major  tasks  include 
the  following: 


Analysis 


Design 


Potential  Diagnostic  Technologies 
Technician's  Role  in  Diagnostics 
Evaluation  of  PAVE  SPRINTER  Capabilities 


Definition  of  IMIS  System 

Develop  Software  Design  and  Interface 

Requirements 

Conduct  Man-Machine  Interface  Studies 


Develop  Test  Plan 


Development 


Develop  Software 

Construct  Hardware  Interface 

Develop  Technical  Data  and  Diagnostic  Data 

Lab  Integration  Test 


Flight  Demo 

(1)  Prepare  and  Support  Flight  Test 

(2)  Validation  of  Diagnostic  Techniques 

(3)  Validation  of  Man-Machine  Interface 

Report  and  Draft  Specifications 


5.  Milestones.  See  Figure  4-4. 
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RECOMMENDED  DEMONSTRATION  #3 


1.  Title:  Reliability  and  Maintainability  in  Computer-Aided 

Design  (RAMCAD) 

2.  Objective.  Demonstrate  and  document  the  benefits  of 
integrating  R&M  analysis  into  computer  aided  engineering  and 
design  systems.  A  comprehensive  capability  to  do  CAD-based 
reliability  and  maintainability  analyses  needs  to  be  developed 
and  demonstrated.  This  will  require  a  number  of  RAMCAD 
demonstrations  to  be  conducted  in  several  areas:  the  use  of 
historical  data  to  feed  a  CAD  based  R&M  analysis;  CAD-based 
predictions  of  MTBF ,  MTTR,  etc.,  scenario  simulations;  etc. 
However,  as  important  as  each  of  these  demonstrations  are,  the 
critical  demonstration  is  one  of  integration.  Several  CAD-based 
RM&L  analyses  need  to  be  pulled  together  and  be  applied  on  a 
single  hardware  program. 

3.  Description.  The  opportunity  to  significantly  improve  the 
ability  of  the  defense  industry  to  design  for  supportability 
exists  because  of  the  explosive  emergence  of  Computer-Aided 
Design  (CAD)  as  the  standard  procedure  of  American  industry.  One 
of  the  reasons  for  this  rapid  growth  is  that  CAD  greatly  reduces 
the  calendar  time  and  engineering  man-hours  required  to  create  a 
new  design  while  simultaneously  producing  higher  quality  results. 
Productivity  improvements  of  4:1  and  higher  are  often  reported. 

The  defense  industry  is  a  world  leader  in  the  area  of 
Computer-Aided  Design.  However,  the  use  of  CAD  to  address 
reliability,  maintainability,  and  logistics  is  still  its  infancy. 
While  there  are  isolated  activities  which  are  adapting  R&M 
techniques  for  CAD,  they  are  primarily  IR&D  programs  and  not  yet 
part  of  the  engineering  mainstream. 
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The  RAMCAD  integration  demonstration  should  take  the  best 
CAD-based  RM&L  analyses  and  latch  these  together  into  a  single 
system.  (This  may  require  some  adaptation  of  existing  models  and 
software.)  This  system  should  then  be  demonstrated  on  a  hardware 
design  (redesign)  effort  of  moderate  size.  All  RM&L  analyses 
required  to  ensure  a  completely  supportable  design  would  be 
available  through  the  RAMCAD  (CALS)  workstation.  (See  CALS 
equipment  design  influence  write-up  Section  II. B.  IDEF  A2.)  Given 
sufficient  resources,  this  demonstration  may  be  completed  within 
three  years. 

These  chief  tasks  facing  the  demonstration  team  will  be 
these: 

a.  To  identify  the  models/analyses/packages  to  be 
integrated . 

b.  To  integrate  them  into  one  system  available  on  a  single 
CAE  computer  hardware/software  configuration. 

c.  To  identify  the  hardware  design/redesign  effort  to  be 
used  as  a  demonstration  vehicle. 

d.  To  conduct  the  demonstration  and  document  the  results. 

By  appropriately  structuring  the  demonstration,  a  number  of 
difficulties  may  be  avoided.  For  example,  a  comprehensive  RAMCAD 
capability  can  be  developed  and  demonstrated  on  a  single  CAE 
system  (Computer-Vision,  application,  CADAM,  etc.)  without 
waiting  for  all  the  inter-system  communication  problems  to  be 
solved.  This  will  greatly  speed  the  development  effort  while 
reducing  the  risk. 

4.  Benefit.  It  is  clear  that  we  need  to  make  quantum 
improvements  in  the  supportabi lity  of  our  weapons  systems  if  we 
are  going  to  fulfill  the  objectives  outlined  by  the  Service  plans 
for  the  year  2000.  Just  as  70  percent  of  life  cycle  costs  of  a 
weapon  are  set  in  early  design,  so  too  are  the  general  support 
characteristics  (down  time,  refueling  time,  spares  required, 
etc.).  By  fully  integrating  R&M  into  CAD,  RAMCAD  will  make  ILS  a 
true  design  function,  giving  it  even  effectiveness  never  before 
achieved.  RAMCAD  will  allow  us  to  design  the  required 


supportability  characteristics  into  the  weapon  systems  up  front. 
This  will  result  in  systems  which  are  more  reliable,  more 
maintainable,  and  cheaper  to  operate. 

In  addition  to  bringing  RM&L  into  early  design,  RAMCAD  will 
allow  far  more  accurate  and  complete  analyses  to  be  regularly 
performed.  This  is  because  CAD  is  very  fast  and  enables 
engineers  to  develop  and  evaluate  several  configurations  in  the 
time  it  is  used  to  accomplish  one.  Because  design  errors  will  be 
reduced  in  number  and  caught  earlier,  expensive  redesign  for 
logistics  will  be  avoided,  speeding  the  acquisition  cycle  and 
sharply  reducing  the  time  required  to  field  truly  supportable 
systems . 

5.  Related  Activities.  There  are  a  number  of  activities 

directly  related  to  conducting  a  RAMCAD  demonstration.  These 
include:  AFHRL’s  maintenance  and  logistics  factors  in  the 

Computer-Aided  Design  program  which  is  conducting  a  series  of 
demonstrations  documenting  the  benefits  associated  with  limited, 
isolated  RAMCAD  analyses;  NCSC's  Computer-Aided  Engineering  for 
testability,  which  is  building  testability  tasks  for  integration 
into  CAD;  RADC’s  ORACLE  developments;  NSIA's  MLCAD  study  group 
work,  which  is  polling  industry  on  commercially  available  RAMCAD 
models,  the  Army  ECAM  program,  the  IDA  RAMCAD  Specifications 
Study;  and  finally  the  JLC  RAMCAD  subpanel  efforts.  In  addition 
to  the  above  activities,  most  aerospace  firms  have  limited  IR&D 
efforts  underway. 

6.  Implementation.  The  RAMCAD  demonstration  can  be  completed 
in  three  years.  A  single  agency  should  be  identified  to  manage 
the  effort  with  sufficient  resources  to  accomplish  the  task. 

This  would  include  4-5  people  to  manage  it  and  10-15  million  over 
a  3-year  period.  This  agency  would  then  manage  the  effort, 

accelerating  the  existing  Service  efforts  (above)  and  identifying 
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an  appropriate  demonstration  vehicle.  Given  the  relative 
sophistication  of  CAE  for  electronics  and  the  extensive  work 
already  accomplished  in  this  area,  an  avionics  system  is 


recommended  for  the  initial  demonstration  focus.  This  would  also 
allow  a  demonstration  to  be  conducted  that  be  would  applicable 
across  all  three  Services. 

By  leveraging  efforts  currently  underway,  the  RAMCAD 
demonstration  will  greatly  shorten  the  time  required  to  conduct 
the  demonstration,  reduce  the  technical  risk,  and  speed  the 
benefits  to  be  achieved  from  the  high  levels  of  system 
reliability,  maintainability  and  availability  which  will  be 
routinely  achieved  when  RAMCAD  is  implemented  across  the  broad  in 
industry  design  procedure. 

7.  Milestones. 

Identify  Implementation  Agency 

Identify  Functions/Analyses  to 
be  Automated 

Adaptat ion/Autoraat ion/ I nte- 
gration  of  Models 

Identify  Demo  Vehicle 

Demonstrate  RAMCAD  in  Decision/ 

Design  of  Demo  Vehicle 
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IQ  FY  87  -  4  FY  88 


RECOMMENDED  DEMONSTRATION  #4 


1.  Title:  Automated  LSAR  Input 

2.  Objective.  The  objective  of  this  demonstration  is  to 
develop  and  demonstrate  the  capability  to  automatically  input 
data  to  the  Logistic  Support  Analysis  Record  (LSAR).  This 
capability  will  extract  data  from  the  CAD  Engineering  Data  Base 
and  other  automated  systems  and  load  then  directly  into  the  LSAR. 

3.  Background .  Today  the  LSAR  (required  by  MIL-STD  1388-2A)  is 
a  highly  labor  intensive,  cumbersome,  unresponsive  and  expensive 
process.  One  of  the  objectives  of  MIL-STD-1 388-2A  is  to  ensure 
that  support  is  properly  considered  in  the  design  of  new  weapon 
systems.  Unfortunately,  because  of  the  complexity  of  the  design 
process  and  the  movement  toward  specialization,  this  objective 
has  never  been  completely  realized.  At  most  defense  contractors, 
the  LSAR  is  accomplished  by  logistics  specialists  completely 
removed  from  the  design  process  in  both  time  and  space.  As  a 
result  the  LSAR  is  after  the  fact,  has  little  or  no  effect  on  the 
design,  and  is  viewed  by  many  contractors  as  an  unnecessary  and 
expensive  requirement. 

In  order  to  reduce  the  cost  for  the  preparation  of  LSARs, 
many  contractors  have  invested  in  an  automated  LSAR  software. 

This  has  allowed  them  to  automate  much,  of  the  records  keeping  and 
do  limited  analyses,  with  sophisticated  LSARs.  However,  even  in 
the  best  circumstances,  the  information  is  input  manually  through 
a  keyboard. 

Paralleling  this  movement  toward  automated  LSARs  has  been  a 
very  rapid  growth  in  the  automation  of  design  and  manufacturing 
processes.  Most  defense  contractors  do  a  significant  portion  of 


their  new  design  using  computer-aided  engineering  methods.  Some 
companies  do  all  of  their  new  designs  using  CAE  and  many  expect 
to  do  so  in  the  very  near  future.  This  has  had  a  number  of 
results : 

o  Because  they  are  not  yet  hooked  into  the  CAE 

environment,  the  logistics  specialists  completing  the 
LSAR  do  not  have  access  to  the  latest  configuration  to 
analyze . 

o  Often  the  logistics  specialists  duplicate  analyses 

(reliability,  maintainability)  which  were  previously 
done  by  the  design,  reliability  or  maintainability 
engineers  during  the  part's  design  phase. 

o  The  increased  productivity  of  the  design  engineer  using 
CAE  puts  the  logistics  specialist  farther  behind  the 
curve  in  terms  of  influencing  the  design. 

o  In  the  most  automated  companies  logistics  specialists 
are  literally  taking  data  from  one  automated  system 
(CAE)  and  manually  keying  them  into  another  (the 
automated  LSAR )  . 

The  demonstration  is  aimed  at  addressing  each  of  these 
issues,  thereby  steamlining  this  expensive  process,  reducing 
errors,  and  eliminating  duplication  of  effort,  making  it  less 
expensive,  faster,  more  responsive,  and  ultimately,  through  the 
use  of  CAE,  a  true  part  of  the  design  process. 

3.  Description.  The  automated  LSAR  input  demonstration  will 
take  information  directly  from  the  CAE  data  base  and  enter  it 
into  the  LSAR  without  human  intervention.  Once  this  interface  is 
successfully  demonstrated,  the  next  step  is  to  reverse  the  flow 
of  information  so  that  the  LSAR  information  is  available  to  do 
comparability  analysis  via  CAD.  Next,  an  assessment  of  the 
usefulness  of  the  automated  input  to  the  LSAR  will  be  required. 


The  demonstration  should  take  a  specific  automated  LSAR  and 
interface  it  directly  with  a  specific  CAE  workstation  that  will 
form  a  fundamental  part  of  the  CALS  workstation  and,  as  such, 
should  be  fully  cognizant  of  the  relevant  standards  and 
protocols.  However,  the  ability  to  interface  directly  with  CAE 
because  of  its  importance,  should  be  demonstrated  completely 
before  integration  into  the  CALS  workstation  occurs. 

4.  Implementation .  There  are  a  number  of  related  activities. 

Each  major  defense  company  has  some  automated  LSAR  and  at  least 
one  CAE  system.  Some  companies  have  begun  to  work  through  the 
problem  of  interfacing  LSAR  with  CAE.  The  Air  Force  has  begun  a 
study  to  look  at  interfacing  their  automated  LSAR  (the  Unified 
Data  Base  for  Logistics  Information)  with  a  CAE  workstation. 

These  activities  should  be  accelerated  and  this  demonstration 
should  be  initiated.  It  could  be  accomplished  within  3  years  for 
a  cost  of  $3  million. 


5.  Milestones. 

Select  a  Automated  LSAR  3  Qtr  85 
Select  a  CAE  system  3  Qtr  85 
Define  Interface  2  Qtr  86 
Implement  Interface  2  Qtr  87 
Demonstrate  Linkage  4  Qtr  87 


Demonstrate  and  Document 
Benefits 


3  Qtr  88 


RECOMMENDED  DEMONSTRATION  #5 

1 .  Title;  Automation  of  Classic  Logistic  Data  Item 

2.  Objective.  The  demonstration  will  employ  computerized 
techniques  to  prepare  a  classic  logistic  data  item  (i.e.,  Support 
Equipment  Recommendation  Summary)  in  its  presently  specified 
format  directly  from  an  LSAR  data  base.  This  will  bridge  the  gap 
between  near  term  and  future  data  acceptance,  while  at  the  same 
time  demonstrating  that  all  duplication  of  effort  between  LSAR 
and  the  additional  data  items  that  are  duplicative,  but  yet  still 
required  by  data  users,  can  be  eliminated. 


3.  Description.  Users  of  classic  data  items  are  accustomed  to 
the  format  that  has  been  specified  over  the  years.  Therefore, 
they  still  glean  the  information  necessary  for  their  use  from  a 
structured  format  with  which  they  are  intimately  familiar.  The 
format,  in  turn,  is  merely  an  arrangement  of  technical  data  and 
information  which  is  mostly  derived  from  design  information,  and 
with  which  the  contractor  is  also  familiar.  The  LSAR 
specifications,  namely  MIL-STD- 1 388- 1 A  and  -2A,  have  defined  a 
disciplined  way  to  collect  and  label  the  data  fields  that  are 
necessary  for  logistics  resource  planning  and  acquisition. 
Normally  the  contractor  prepares  the  classic  data  items  in 
parallel  with,  or  sometimes  even  ahead  of,  LSAR  preparation.  The 
classic  data  items  are  still  being  used  for  the  actual  resource 
planning  and  acquisition,  rather  than  the  LSAR.  It  stands  to 
reason  that  if  the  elemental  data  fields  would  serve  the  purpose 
for  input  to  the  LSAR,  as  well  as  input  to  the  preparation  of  the 
classic  data  items,  that  the  LSAR  data  base  could  be  used  to 
prepare  the  data  items. 

If  that  assumption  is  true,  then  the  automation  of  the  LSAR, 
as  it  exists  today  for  its  own  internal  data  sorting  into  output 
summary  reports,  could  very  well  be  modified  to  automatically 


prepare  the  classic  data  items.  In  turn,  having  demonstrated 
that,  the  next  logical  step  could  very  well  be  that  the  data  item 
could  be  eliminated  completely,  and  the  users  of  that  data  could 
interrogate  the  LSAR  data  base  directly  for  input  into  their  his 
decision  making  process.  This  of  course  would  save  the  expense 
and  manpower  demands  for  data  item  preparation  as  well  as  the 
preparation  of  LSAR  output  summary  reports  and  their  subsequent 
translation. 

To  provide  credibility  that  this  would  work,  the  experiment 
would  need  a  control.  The  control  could  simply  be  the 
preparation  of  the  candidate  data  item  by  the  classical  manual 
means.  The  resulting  outputs  could  then  be  compared  and  should 
prove  to  be  identical. 

The  demonstration  would  start  by  preparing  the  data  fields 
for  the  candidate  item  in  precisely  the  same  manner  as  if 
inputting  to  the  LSAR.  Since  automatic  LSAR  inputtng  is  not  a 
necessary  part  of  this  experiment,  manual  collection  and 
inputting  of  these  data  would  be  acceptable.  However,  the  LSAR 
would  have  to  be  able  to  transform  these  data  automatically  into 
the  presently  specified  -2A  structure.  Once  in  the  data  base, 
the  data  base  would  be  interrogated  by  a  combination  of  data  base 
management,  analytical,  and  text-processing-type  programs  which 
will  rearrange  the  raw  data  contained  in  the  LSAR  data  base  into 
the  data  fields  required  by  the  data  item.  Summarization  and 
analyses,  if  necessary,  will  be  also  handled  by  that  program. 

The  demonstration  will  continue  with  proving  that  the  data  so 
collected  and  structured  can  be  traced  to  the  configuration  of 
the  item  that  they  represents,  either  by  the  LSAR  numbering 
system,  or  by  some  other  scheme  yet  to  be  defined.  Ease  of 
updating  and  archiving,  beyond  that  available  with  paper  data, 
must  also  be  demonstrated. 
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Implementation 


4.1  Technical  Requirements.  The  technical  requirements  for 
this  demonstration  could  range  from  relatively  simple  to  very 
complicated,  depending  on  the  data  item  that  is  chosen.  A  data 
item  that  needs  only  rearrangement  and  minor  calculations,  such 
as  a  Support  Equipment  Requirements  Document,  will  not  require 
complex  or  expensive  computer  techniques  to  accomplish  the 
demonstration.  On  the  other  hand,  a  data  item  such  as  a 
Calibration  Requirements  Summary  would  be  much  more  difficult, 
and  expensive  to  demonstrate.  For  the  simpler  case,  an  automated 
LSAR  program  such  as  the  UDB  will  be  required.  As  mentioned 
previously,  normal  manual  inputting  would  suffice  for  the 
purposes  of  this  experiment,  although  of  course  automatic 
inputting  would  be  of  still  greater  value.  The  data  base  manager 
which  will  extract  the  information  from  the  LSAR  data  base  will 
need  to  be  designed,  as  will  the  interaction  with  the  text 
processor,  and  whatever  analytical  techniques  are  deemed 
necessary.  This,  however,  is  not  beyond  the  state  of  the  present 
computer  techniques  available  commercially,  especially  in  the 
personal  computer  industry. 


4.2  Available  Material. 


There  are  several  automatic  LSAR 


preparation  procedures  available.  The  Air  Force's  UDB  used  on 
the  B-1  program  is  just  one  of  these.  There  are  also  independent 
industry  efforts  available  for  the  automatic  data  preparation  of 
some  limited,  simple  data  items.  These,  however,  do  not  use  the 
LSAR  data  base  to  do  this,  but  rather  use  the  inputs  which  are 
normally  derived  from  engineering  information.  However,  these 
programs  can  help  in  structuring  the  data  preparation  software 
system  to  interact  with  the  data  base  manager  and  text  processor. 

4.3  Required  Resources.  The  demonstration  would  be  rather 
simple  to  get  underway.  Contractors  who  are  presently  using  an 
LSAR  data  base  system  would  be  solicited  to  (a)  provide 
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suggestions  as  to  which  data  item  would  prove  a  good  candidate, 
as  well  as  (b)  what  hardware  itera(s)  would  be  most  feasible  to 
perform  the  demonstration  on,  to  provide  a  good  cross  section  of 
support  equipment  types.  These  contractors  could  then  be  asked 
to  quote  the  demonstration.  Therefore,  only  financial  resources 
are  really  necessary. 

5.  Milestones. 


Identify  Implementing  Agency  3Q  FY  85 
Solicit  Contractor  to  Provide  Suggestions  3Q  FY  85 
Select  Hardware  System  3Q  FY  85 
Select  Data  Item  3Q  FY  85 
Prepare  Computer  Programs  2Q  FY  86 
Prepare  Data  Item  IQ  FY  87 


RECOMMENDED  DEMONSTRATION  #6 


Title:  Computer  Aided  SDecification/RFP  Preparation 


2.  Objective.  To  demonstrate  that  reliability,  maintain¬ 
ability  and  supportabi lity  equipment  design  attributes  can  be 
developed  as  part  of  a  specif iction' s  performance  requirements  by 
computer  interaction  with,  and  prompting  of,  the  authors.  The 
specification  would,  as  part  of  an  RFP,  be  sufficiently  specific 
that  the  appropriate  design  features  would  be  provided  by  the 
designer,  taking  advantage  of  the  competitive  leverage  during  the 
proposal  phase. 


Description. 


The  demonstration  would  be  limited  to  one  or 


two  aspects  of  reliability  and  maintainability  issues  that  are 
design  driven.  Demonstration  would  also  be  limited  to  a 
reasonably  small  subsystem  so  that  the  required  initial 
programming  would  not  be  overwhelming.  It  is  suggested  that  the 
attributes  of  reliability’s  mean  time  between  failures  and 
maintainability's  built-in-test  be  selected  as  the  candidates, 
because  of  their  importance  to  readiness  and  sustainability. 
Unlike  other  programs  available  today  which  assemble  information 
from  a  library  of  "canned"  statements,  this  program  would  develop 
statements  by  interaction  with  the  government's  systems  or 
equipment  engineer  as  he  prepares  the  performance  specification 
requirements . 

The  result  would  give  an  entirely  new  look  to  the 
reliability  and  maintainability  contents  of  a  specification,  in 
that  the  "real"  requirements  would  become  part  of  the  performance 
requirements  in  Section  3  of  a  specification.  Statistical 
figures  of  merits,  if  they  are  really  needed,  could  then  be 
developed  from  these  statements  to  be  included  into  the  RFP's 
reliability  and  maintainability  sections. 


As  an  example,  assuming  that  a  radar  set  is  being  specified, 
and  that  the  aircraft  sortie  rate  and  minimum  required  turn 
around  time  have  been  established  by  the  user,  along  with  the 
mission  profile  requirements  for  that  radar,  the  following  kind 
of  interactive  prompting  would  result  in  specification  statements 
that  the  design  engineer  must  address  as  part  of  his  design 
rather  than  the  customary  design,  analyze,  rearrange  the 
apportionments,  try  it  again,  etc. 

The  engineer  may  prepare  a  statement  such  as:  "minimum 
target  cross  section  shall  be  two  feet,  at  a  maximum  range  of  ten 
miles".  He  may  then  be  asked  by  the  program:  "if  this 
requirement  is  not  met  during  a  mission,  what  would  you  like  to 
see  happen",  and  give  him  a  menu  to  choose  from: 

a.  Depends  on  how  bad  it  is. 

b.  Warn  pilot,  with: 

(1)  Alarm 

(2)  Alert  lamp 

(3)  Status  panel 

(4)  Switch  to  redundant  radar 

If  he  should  have  answered  (a),  another  set  of  prompts  would 
come  up  immediately:  "In  these  statements  you  have  made,  what  is 
the  worst  that  you  could  live  with  during  the  heat  of  a  battle?": 

a.  If  that  threshold  is  reached  what  should  take  place?: 

(1)  Alarm 

(2)  Alert  lamp 

(3)  Status  panel 

(4)  Switch  to  redundant  radar 

b.  Performance  has  degenerated  beyond  that  threshold  to 
(specify  the  degree),  what  should  happen?: 

(1)  Alarm 

(2)  Alert  lamp 


(3)  Status  panel 

(4)  Switch  to  redundant  radar 

c.  If  the  threshold  has  been  crossed  beyond  (b),  what 
should  happen?: 

(1)  Alarm 

(2)  Alert  lamp 

(3)  Status  panel 

(4)  Switch  to  redundant  radar 

Another  question  which  might  help  him  make  the  decision 
regarding  what  he  should  put  into  the  answers  could  be:  "is  the 
target? " : 

a.  Life  threatening. 

b.  Is  countermeasures  possible  within  _  seconds  of 

closing,  (here  the  program  could  check  the  tolerances  given  on 
the  range  from  knowledge  of  the  missiles  and  the  aircraft  which 
have  been  input  prior  to  starting  this  session,  and  feed  this 
back  to  the  engineer  so  that  he  may  adjust  his  answers). 

c.  Not  life  threatening  but  mission  essential. 

d.  Neither  life  threatening  nor  mission  essential. 

If  he  answered  (c)  or  (d)  the  prompts  could  ask  him  to 
reconsider  his  previous  answers,  if  they  reflect  a  potential 
overkill  by  the  engineer. 

All  this  would  define  what  self-test  and  self-healing 
features  the  designer  must  include  to  provide  specified  action. 

Reliability  related  interrogations  could  be  questions  such 
as:  "is  the  appearance  of  the  target  under  the  pilot’s 

control?",  Yes  or  No.  If  the  question  was  answered  "Yes",  then: 
"is  mission  workaround  possible?",  Yes,  No,  Not  Essential. 

From  knowledge  of  the  mission  duration,  whether  this  was  a 
missile  or  not,  and  from  previous  answers,  the  program  could  now 
compute  serial  and  parallel  reliability  figures  of  merits  for  the 


performance  function,  which  in  this  case  was  target  cross  section 
recognition  capability. 

To  respond  to  this  (in  the  proposal  or  design),  it  would  be 
up  to  the  design  engineer  to  consult  with  the  reliability 
engineer  as  to  the  apportionment  of  the  failure  rates  to  the 
circuit  components  which  are  planned  for  use.  In  this  way  there 
would  be  no  doubt  that  that  particular  function  has  been 
addressed  as  a  required  performance  function,  and  not  merely  as  a 
part  of  a  pool  of  failures,  which  may  have  nothing  to  do  with 
that  function. 

The  data  collected  by  the  program  from  this  interrogation 
can  then  be  handled  in  several  ways  (the  handling  would  depend  on 
how  sophisticated  a  technique  is  desired  to  be  demonstrated). 

The  simplest  would  be  to  feed  that  information  back  to  the 
engineer-author  so  that  he  could  structure  it  into  statements 
which  will  be  included  as  subparagraphs  to  the  particular 
performance  requirement;  or  the  program  could  search  a  library  of 
"canned"  phrases  to  which  the  information  gleaned  from  the 
various  responses  is  added,  so  that  actual  sentences  or 
subparagraphs  are  generated  by  that  program. 

4.  Implementation 

I 

4.1  Technical  Requirements.  Having  chosen  a  candidate  system, 
a  typical  performance  specification  for  such  a  system  would  be 
researched  by  a  team  consisting  of  a  design  engineer,  reliability 
engineer,  and  maintainability  engineer,  who  would  prepare 
appropriate  questions  similar  to  those  above,  which  would  be  used 
by  a  programmer  to  develop  the  interactive  program.  If  the 
candidate  specification  were  relatively  simple  as  concerns 
technical  requirements,  then  a  small  computer  such  as  an  IBM  PC 
would  suffice  to  conduct  the  experiment.  Therefore,  a  computer 
and  printer  and  the  four  professional  talents  previously 
mentioned  are  all  that  will  be  required  to  develop  the  input. 

The  resultant  specification  however, 
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should  be  tested  by  a  different  team  consisting  of  a  design 
engineer,  reliability  engineer,  and  maintainability  engineer,  for 
an  independent  assessment  of  understanding  and  acceptability. 

4.2  Existing  Technologies/Developments .  Presently  there  are 
on-going  programs  for  authoring  specifications.  However,  these 
are  not  interactive  programs,  in  the  sense  that  they  would 
interact  with  the  illities  to  prepare  the  performance 
requirements.  Rather  they  are  mind-joggers  and  pat-phrase 
assembly  type  of  programs,  to  take  "canned”  statements,  ask  the 
author  to  modify  them  slightly  and  then  assemble  a  specification 
from  that.  This  type  of  program  would  be  helpful  in  the  final 
assembling  of  the  specification  to  be  demonstrated.  Interactive 
programs  also  exist  for  different  applications  in  the  private 
sector,  such  as  the  ELISA  program,  which  is  an  interactive  game. 
The  techniques  used  in  that  program  are  precisely  what  are  needed 
here  for  interaction.  Another  existing  program,  and  there  are 
many  of  these  in  the  private  sector,  is  the  program  called  Think 
Tank.  This  is  a  data  base  program  that  is  able  to  expand  and 
collapse  notes  in  such  a  way  that  they  can  be  assembled  into  any 
final  document.  The  program  allows  rearranging,  ordering  of 
priorities,  etc.  This  type  of  program  would  be  very  helpful 
also.  In  all,  there  are  examples  of  such  programs  in  different 
applications  available  today.  Therefore,  the  programming 
technique  need  not  be  invented,  rather  an  application  of  existing 
techniques  is  all  that  is  necessary. 

4.3  Getting  Started.  This  entire  demonstration  could  well  be 
conducted  by  the  Air  Force’s  Human  Resources  Lab,  since  the 
required  skills  for  preparation  of  a  specification  in  the  area  of 
performance,  reliability  and  maintainability  exists.  Therefore, 
the  starting  process  only  requires  tasking  statements  and 
budgets.  The  review  of  the  output  should  really  be  conducted  by 
industry.  To  do  that  a  contract  would  have  to  be  prepared,  and 
funding  made  available.  A  better  alternative,  which  would  avoid 


the  contracting  issues,  would  be  to  engage  IDA  in  that  study 
entirely,  since  both  the  Services  and  industry  representatives 
are  available  to  IDA. 


Milestones. 


5.1  Identify  Implementing  Agency 

Select  a  Sample  Portion  of  a  Specification 
Solicit  Contractor  to  Quote  the  Requirement 
Design  the  Program 
Run  Sample 

Analyze  Results  and  Prepare  Report 


3Q  FY  85 
3Q  FY  85 
4Q  FY  85 
4Q  FY  86 
4Q  FY  86 
IQ  FY  87 
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